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

[Marc Weber]

Hi Peter,

Excerpts from Peter Simons's message of Mon Feb 07 19:11:12 +0100 2011:
> The disadvantages seem to be:
I'd like to give it a try. The build changes seem to be simple (some
symlinking was done).
 
>  - 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.
IMHO we should take the risk. For 2.7 it is very unlikely to happen.
About 3.x or future I don't know.

>  - It's not clear how that expression might run regression tests for the
>    modules its building.
You're talking about make test or doCheck=true or such?
Maybe we can fake the environment just enough to run those tests as
well?
 
> 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 [..] such as in a user profile. [..]
We could address this easily by providing a meta package containing
python and those packages. Users could install that instead.

> modular-python, it's no longer possible to build such a binary,
Explain. Why do you think its no longer possible?

Eg have a look at misc.collection which did this for years.
The items were pythonFull and some libraries instead of python + core
libs of python.

> 'python' interpreter found in a user profile would have no idea how to
> import sqlite3 or Tkinter or any other extra module
Agreed. Python usually hase one PYTHONUSERBASE.
The pitty is:  It works with your profile - but not when building
packages - because you don't have an assembled env yet.

And this problem is not new: pygtk suffers from it the same way.
Usage is like this:

  import pygkt
  pygtk.require('2.0')

what does this code do?
It looks for the installation path of pygobject. Then it adds a pgkt/2.0
or such to sys.path.

What's the problem? Other packages such as pygnome will create $out/.../pygtk/2.0
but adding one path to sys.dir is not enough anymore. You have to
iterate over sys.path (or buildInputs) and add all $out/pygtk/2.0 of all
packages. Then its fine and it works.

The current hack is to ignore the '2.0' and symlink the libs into a
dircetory which is found by default by toPythonPath.

I've had some trouble with this approach when trying to run the
vodafone-network-manager. But one hour was not enough to track down the
issue. The iterate over all paths adding /pygtk/2.0 worked.

So the same could be done for modular python. I introduced NIX_PYTHON_PATH
trying to make it behave like PYTHONUSERBASE but allow multiple paths.

> modules are shipped as part of the Python distribution.
My guess is that the nixpkgs forces us to look at problems in a creative
way leading to solutions serving our daily work best.

I'm for having one python only - either by using the modular change or
by keeping *Full only. Probably everyone is using X and tcl/tk in some
way anyway (eg gitk) ?

If nobody minds I'll try applying Eelco's work on python 3.x.

Marc Weber