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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
