[Nix-dev] Re: Python 3

[Lluís Batlle]

Hello all,

sorry to trigger this thread up again, but I think that the discussion
was worth a continuation. I'll try to summarize what I understand:
- Peter wants nice expressions for python, to work like most nix c
packages do: a derivation for each lib, a derivation for the
interpreter, and the interpreter set as the elf interpreter is set for
elf binaries, equivalently for python versions.
- Marc wants some python programs to work soon, and the actual "old"
python expressions don't work for him, as they don't manage well the
.pth stated dependencies, and even some more tricks as pygtk require
function.

I think that the actual "old" python code makes use of a generic
wrapper written for every python program, which sets the PYTHON_PATHS
(which doesn't cover the .pth files used by *some* python packages, as
pygtk).

Not only the .pth files, but also the pygtk require() function make
some tricks for loading the proper library version at run time. In
short, that function checks for libraries at `pwd`/../gtk-ver (to find
gtk for example), and the version of gtk to be used is determined at
load time of pygtk, not at build time of pygtk.

I'm thinking of two different problems to solve, to which Marc gave
two solutions:
- For pygtk, making all gtk things sit in the same store path, so ".."
references are properly resolved.
  - As another solution, I suggest to make the 'pygtk' expression a
function, which has the gtk version as a parameter, and the derivation
works only for that gtk version. We (meaning "I hope not me") can
patch the pygtk.py loader to stop the ".." thing and match only that
gtk version. Python programs needing pygtk would need nix explicit
setting for the gtk version they will "import" at runtime.
- For the .pth files, these are fixed per python module. At the nix
expression for the given module, the paths mentioned in the .pth files
could be added to the PYTHON_PATHS in the actual "old" python
expressions, right?

I think Marc was specially afraid about having a very big PYTHON_PATH,
but I don't understand whether that came from the pth files problem (I
don't think it can grow too big for that), or it came from the pygtk
super-duper-runtime-library-version-checking, about which he thought
about multiple gtk versions and multiple python modules needing them?

I don't think I understand the problems profoundly enough, but I think
each post brought more information into the discussion, allowing me to
take part into it. But the discussion stopped, and I don't understand
where stopping brings the python expressions to.

Agreeing with Peter and Marc, I don't think the actual "old" system
allows loading of something like pygtk. And I also don't like putting
a bunch of libraries in the same path.

So, is it me not understanding this at all, or there were two mixed
issues (pygtk require and pths), not necessarily to be mixed?

At the expect of some light,
Lluís.

2009/2/20 Peter Simons <simons at cryp.to>:
> Hi Marc,
>
> in e-mail communication, it's easy to be misunderstood, particularly when
> people talk who don't know each other in person. It's hard to interpret what
> the other person is saying, because those non-verbal clues that we'd
> normally have -- facial expression, sound of the voice, etc. -- are lacking.
>
> Now, I'm somewhat embarrassed to say this, but my impression is that you're
> reluctant to discuss this subject, or, more precisely, you seem to be
> reluctant to discuss it with me. The dependency question clearly interests
> you, because you participate in other threads about the topic, but for me it
> seems to be very hard to get a response from you. It feels like most of the
> contents of my last few e-mail doesn't really sink into your consciousness.
>
> When I have that impression, it usually means that I express my thoughts
> poorly. That happens sometimes.
>
> For the time being, I suggest we agree to disagree, sort of, and just leave
> things as they are on the Python front.
>
> Take care,
> Peter
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>