Python: split buildPythonPackage into two functions

[FRidh]

Motivation for this change

Currently we have only buildPythonPackage for setuptools and wheels installations. However, we still have quite some packages that do not use setuptools or wheels. This PR provides another function, mkPythonDerivation, that

• sets pythonPath so buildEnv will function
• adds the python interpreter which was typically missing
• wraps the Python programs

thus solving issues like described in #17679.

A rebuild is needed.

[mention-bot]

@FRidh, thanks for your PR! By analyzing the annotation information on this pull request, we identified @domenkozar, @adnelson and @abbradar to be potential reviewers

[FRidh]

Packages to convert (see #17679):

• PyXML
• PyXAPI
• bsddb
• crypt
• curses_panel
• dbus
• fedora_cert
• gdbm
• gst-python
• libvirt
• notify
• pyblock
• pycairo
• pygobject
• pygobject3
• pygtksourceview
• pyqt4
• pyqt5
• pyside
• pysvn
• pywebkitgtk
• qscintilla
• recursivePthLoader
• sip
• sip_4_16
• readline (*)
• curses (*)
• sqlite3 (*)

[FRidh]

cc @garbas @lancelotsix @layus

[FRidh]

Can we agree on the name of the functions? I need to know this before going any further. If we agree I'll fix the whole list and then we should be able to make it in before we branch tomorrow.

[layus]

@FRidh I like the idea to provide a custom mkDerivation.
After reading the commits, I must say that using the name mkDerivation is extremely confusing. I propose mkPythonDerivation ? In the above commits, it is difficult to tell from the context if mkDerivation comes from python or from stdenv.

[FRidh]

@layus Thanks for the feedback and good point. I hope we eventually have `python.mkDerivation' like is now the case with Haskell and therefore chose that name. But changing it is no problem.

[layus]

Yes, python.mkDerivation looks good at first, but if people do like below, then the ambiguity persists :-).

{ ... }:
with stdenv;
with python;

...

mkDerivation { 
    ...
}

[lsix]

@FRidh that's great (and will a good answer to a question I saw recently on the ml http://lists.science.uu.nl/pipermail/nix-dev/2016-August/021466.html).

I do not have a strong opinion about mkPythonDerivation vs mkDerivation. I am not sure how often someone will end-up with both stdenv and python “withed”. Seems to me that most cases will be like what you did when updating the first derivations:

• import lib instead of all stdenv
• use a pythonPackage set argument and build from its mkDerivation.

That said, I have no objection calling the function mkPythonDerivation to make sure there will never be ambiguities.

I will try have a closer look later on the whole PR later today.

[adnelson]

Yeah I second the opposition of mkDerivation. I'm not a fan of it with the Haskell ecosystem either. mkDerivation to me is a sort of "god function" 😝 Honestly I'm not sure what's wrong with buildPythonPackage, although I think something like mkPythonDerivation is fine too.

[adnelson]

I like this conceptually, but is there really anything wrong with just deeming these to be buildInputs?

[FRidh]

Not really. As you can read, they are put together anyway. It might save some building when you disable tests. Furthermore, I'm still playing with the idea of separating the building and installing/testing in two separate derivations.

[FRidh]

Thanks for the feedback.

A bit more about the naming. Looking at what the current mkDerivation and buildPythonPackage do, could you imagine better names for the both? These two names (or mkPythonDerivation) are quite different but they completely don't explain what their difference is.