[Nix-dev] Python refactoring again (second attempt)

[Marc Weber]

Continuation of thread:
  Subject: Re: [Nix-dev] gitorious mirror -Python refactoring again (second attempt)
  Date: Sun, 09 May 2010 23:28:28 +0200
  Message-Id: <1273440254-sup-8101 at nixos>


I think the whole python and pythonFull difference is not worth the
effort thinking about which python version should be used.
Probably everybody has a tcl/tk for some reason anyway.

> The definition of ‘buildPython26Package’ looks somewhat circular to me.
> Am I missing something?
No. You're right. I forgot to drop passing this argument.

> Please keep only one ‘python’ argument.  This function can be called
> with ‘python = pythonFull’ if need be; there’s no need to add a new
> argument.

How would this look like?

python26PackagesFull = pythonPackagesBuilderFun pythonFull;
python26Packages = pythonPackagesBuilderFun python;

Now its the user who has to recognize that he must use

python26PackagesFull.iotop
rather than than
python26Packages.iotop.

Which is unfortunate because it requires the user to know about
implementation details.

Of course we could add a top levl alias:
iotop = python26PackagesFull.itop

Or should I add an assertion (which I should do anyway) and add a
message:

# If you get a failure use pythonFull
assert python.ncursesSupport;
?

> IMO Setuptools doesn’t belong in ‘python-packages.nix’ since it’s not
> built with ‘buildPythonPackage’.

I think everything which belongs to "python" and depends on python
mainly (exceptions pygkt, pyqt etc) should be put there so that you can
pass a different python easily.
I think the decision maker "is build by buildPythonPackage" is not
appropriate.

> ‘doCheck = false’, rather.
Well, unfortunately in Nix is untyped as PHP is.
So in the end you use what works.
Having typed expressions is the only way to enforce this..

Is there a chance to separate the extra libraries from main python
installation?

Eg build pythonFull multiple times only keeping those parts we're
interested in?

Then you can add those dependencies you need on the fly by adding
pythonPackages.ncurses to buildInputs.


There is another issue:

You can't ask the buildPythonPackage function whether the
Python package has xxSuppport or not because it's a function.

So the should be changed to something like:

  pythonAttr = {
    builder = ..;
    python = ...;
  }


then you can do

  assert pythonAttr.python.opensslSupport;
  pythonAttr.builder {
    ...
  }

How do you think about this?

Marc Weber