[Nix-dev] modular-python (was: [Nix-commits] SVN commit: nix - r25748 - nixpkgs/trunk/pkgs/top-level)

[Peter Simons]

Hi Eelco,

 > Have you seen this branch:
 >
 >   https://svn.nixos.org/repos/nix/nixpkgs/branches/modular-python/
 >
 > It gets rid of the distinction between pythonBase and pythonFull
 > entirely. It has a Python package with few dependencies, while those
 > Python modules that require external dependencies (sqlite, tcl/tk,
 > etc.) are moved into separate packages.
 >
 > I didn't do that for Python 3 yet though.

this is very interesting. The obvious advantage of that scheme is that
it's no longer necessary to rebuild Python itself just to enable any
specific permutation of additional features that might be required. This
property allows us to specify precise dependencies in a high
granularity.

The disadvantages seem to be:

 - The expression relies on internals from the Python build system. This
   means that changes to Python's build system might break the
   expression in a non-trivial way. Whether that is likely to happen or
   not is a matter of speculation, though.

 - It's not clear how that expression might run regression tests for the
   modules its building.

Furthermore, our current pythonFull expression is appealing to some
degree, because it produces a 'python' interpreter that knows a fairly
complete set of standard modules. That binary is useful outside of the
context of Nix-driven builds, such as in a user profile. With
modular-python, it's no longer possible to build such a binary, i.e. the
'python' interpreter found in a user profile would have no idea how to
import sqlite3 or Tkinter or any other extra module -- even though those
modules are shipped as part of the Python distribution.

The problem exists today as far as modules from pythonPackages are
concerned.

I wonder how can we address that flaw?

Take care,
Peter