Down with PYTHONPATH!

Down with PYTHONPATH!

[Ricardo Wurmus]

Hi Guix,

here’s a half-baked idea that I think is worth considering: let’s patch
our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
our wrappers.

PYTHONPATH is dangerously inadequate for use in a wrapper.  Consider the
case where a user has Numpy installed with Guix but also uses some
unrelated application that happens to have been installed to
~/.local/bin via pip.

Since numpy is part of the manifest Guix will helpfully record a value
for PYTHONPATH in etc/profile.  It’s very likely that users rely on
etc/profile magic to set all needed environment variables, so PYTHONPATH
will likely be set to a location that makes sense for Python
applications in Guix.

The user now runs ~/.local/bin/myapp and the thing crashes because the
system Python will to load up Numpy from Guix, which is incompatible.
The system Python may even be Python 2.7.

PYTHONPATH is the wrong mechanism for Guix to use.  We have previously
discussed this and Hartmut Goebel analyzed the situation for us in the
past (see the thread containing the message with ID
<ad6b1473-2732-ca7b-d971-e548c39013f6@crazy-compilers.com>).
Unfortunately, we couldn’t decide on a good way forward.

So I propose to avoid using PYTHONPATH, which is similarly dangerous as
LD_LIBRARY_PATH in that it causes incompatible libraries to be loaded.
Switching to GUIX_PYTHONPATH is not going to be a complete solution
(because it doesn’t distinguish between different versions of Python),
but at the very least it will separate Python applications that use Guix
from Python applications that don’t.  Right now this is not the case and
people who use Guix for some things but not for others have a really bad
time and learn to avoid Guix because it sets PYTHONPATH, which breaks
their other applications.

If we’re feeling lucky we could even introduce GUIX_PYTHON2_PATH and
GUIX_PYTHON3_PATH to solve the other half of the problem, namely that
Python 2 applications will load Python 3 libraries (and vice versa).

What do you think?

--
Ricardo

Re: Down with PYTHONPATH!

[ng0]

Ricardo Wurmus transcribed 2.0K bytes:
> Hi Guix,
> 
> here’s a half-baked idea that I think is worth considering: let’s patch
> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
> our wrappers.
> 
> PYTHONPATH is dangerously inadequate for use in a wrapper.  Consider the
> case where a user has Numpy installed with Guix but also uses some
> unrelated application that happens to have been installed to
> ~/.local/bin via pip.
> 
> Since numpy is part of the manifest Guix will helpfully record a value
> for PYTHONPATH in etc/profile.  It’s very likely that users rely on
> etc/profile magic to set all needed environment variables, so PYTHONPATH
> will likely be set to a location that makes sense for Python
> applications in Guix.
> 
> The user now runs ~/.local/bin/myapp and the thing crashes because the
> system Python will to load up Numpy from Guix, which is incompatible.
> The system Python may even be Python 2.7.
> 
> PYTHONPATH is the wrong mechanism for Guix to use.  We have previously
> discussed this and Hartmut Goebel analyzed the situation for us in the
> past (see the thread containing the message with ID
> <ad6b1473-2732-ca7b-d971-e548c39013f6@crazy-compilers.com>).
> Unfortunately, we couldn’t decide on a good way forward.
> 
> So I propose to avoid using PYTHONPATH, which is similarly dangerous as
> LD_LIBRARY_PATH in that it causes incompatible libraries to be loaded.
> Switching to GUIX_PYTHONPATH is not going to be a complete solution
> (because it doesn’t distinguish between different versions of Python),
> but at the very least it will separate Python applications that use Guix
> from Python applications that don’t.  Right now this is not the case and
> people who use Guix for some things but not for others have a really bad
> time and learn to avoid Guix because it sets PYTHONPATH, which breaks
> their other applications.
> 
> If we’re feeling lucky we could even introduce GUIX_PYTHON2_PATH and
> GUIX_PYTHON3_PATH to solve the other half of the problem, namely that
> Python 2 applications will load Python 3 libraries (and vice versa).
> 
> What do you think?

Sounds like a reasonable strategy for avoiding mixed python loading,
and the other cases you described above.
 
> --
> Ricardo
> 

Re: Down with PYTHONPATH!

[Ludovic Courtès]

Hello!

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> here’s a half-baked idea that I think is worth considering: let’s patch
> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
> our wrappers.

Oh!

[...]

> So I propose to avoid using PYTHONPATH, which is similarly dangerous as
> LD_LIBRARY_PATH in that it causes incompatible libraries to be loaded.
> Switching to GUIX_PYTHONPATH is not going to be a complete solution
> (because it doesn’t distinguish between different versions of Python),
> but at the very least it will separate Python applications that use Guix
> from Python applications that don’t.  Right now this is not the case and
> people who use Guix for some things but not for others have a really bad
> time and learn to avoid Guix because it sets PYTHONPATH, which breaks
> their other applications.

The reasoning makes sense to me… but wouldn’t it extend to most of the
*PATH variables?  After all, PERL5LIB or even GUILE_LOAD_PATH could lead
to similar issues, no?

AIUI, the problem is more acute in Python because of pip, and because
people are likely to use both pip and Guix, right?

> If we’re feeling lucky we could even introduce GUIX_PYTHON2_PATH and
> GUIX_PYTHON3_PATH to solve the other half of the problem, namely that
> Python 2 applications will load Python 3 libraries (and vice versa).

My gut reaction is that this is a problem for upstream to solve
(GUILE_LOAD_PATH has the same problem, and AFAICS most PATH variables
are unversioned), but OTOH we’re at the forefront here because we can
usefully mix Python 2 and Python 3 things in an environment.

Thanks,
Ludo’.

Re: Down with PYTHONPATH!

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

>> here’s a half-baked idea that I think is worth considering: let’s patch
>> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
>> our wrappers.
>
> Oh!
>
> [...]
>
>> So I propose to avoid using PYTHONPATH, which is similarly dangerous as
>> LD_LIBRARY_PATH in that it causes incompatible libraries to be loaded.
>> Switching to GUIX_PYTHONPATH is not going to be a complete solution
>> (because it doesn’t distinguish between different versions of Python),
>> but at the very least it will separate Python applications that use Guix
>> from Python applications that don’t.  Right now this is not the case and
>> people who use Guix for some things but not for others have a really bad
>> time and learn to avoid Guix because it sets PYTHONPATH, which breaks
>> their other applications.
>
> The reasoning makes sense to me… but wouldn’t it extend to most of the
> *PATH variables?  After all, PERL5LIB or even GUILE_LOAD_PATH could lead
> to similar issues, no?

Other languages may have similar problems, but I haven’t tested it.

> AIUI, the problem is more acute in Python because of pip, and because
> people are likely to use both pip and Guix, right?

Yes.

>> If we’re feeling lucky we could even introduce GUIX_PYTHON2_PATH and
>> GUIX_PYTHON3_PATH to solve the other half of the problem, namely that
>> Python 2 applications will load Python 3 libraries (and vice versa).
>
> My gut reaction is that this is a problem for upstream to solve
> (GUILE_LOAD_PATH has the same problem, and AFAICS most PATH variables
> are unversioned), but OTOH we’re at the forefront here because we can
> usefully mix Python 2 and Python 3 things in an environment.

Upstream generally doesn’t use PYTHONPATH.  For isolation they use other
mechanism (such as the virtualenv feature), which unfortunately aren’t
flexible enough and thus not applicable for Guix as discussed earlier
based on Hartmut’s analysis.

I think it is a mistake to set these variables globally when they affect
software outside of Guix.  (We have a similar problem with the XDG_*
variables that may suggest to foreign binaries to load incompatible
binaries from Guix, but that’s a different can of worms.)

--
Ricardo

Re: Down with PYTHONPATH!

[Konrad Hinsen]

Hi Ricardo,

> here’s a half-baked idea that I think is worth considering: let’s patch
> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
> our wrappers.
...

I agree with the reasoning behind this and at first sight, your proposal
looks good. But real life is always messier than anybody's theory, so
this needs to be stress-tested before general deployment, in my opinion.

> PYTHONPATH is the wrong mechanism for Guix to use.  We have previously

True, but it's also the wrong mechanism for just about everything else.
The kind of idea that was reasonable in 1990 but didn't scale to more
complex environments.

Nowadays, in the wider world (beyond Guix), PYTHONPATH is mainly a
newbie trap. Experienced pythonistas have abandoned it for virtual
environments. So if it can be turned into a mechanism for supporting
Guix environments with a name change, I doubt anyone would complain
about standard PYTHONPATH being gone.

> If we’re feeling lucky we could even introduce GUIX_PYTHON2_PATH and
> GUIX_PYTHON3_PATH to solve the other half of the problem, namely that
> Python 2 applications will load Python 3 libraries (and vice versa).

Definitely. It solves one more problem at no extra cost.

Konrad.

Re: Down with PYTHONPATH!

[Hartmut Goebel]

Am 14.06.19 um 10:14 schrieb Ricardo Wurmus:

I welcome your initiative. Fixing this finally is on my todo-list since
long.

> here’s a half-baked idea that I think is worth considering: let’s patch
> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
> our wrappers.

I have a *strong* opinion against this, as this would just replace one
cludge by another one. See below for rational.

IMO the only sustainable solution it to patch the interpreter
(Modules/getpath.c) to determine the correct "installation path"
(profile). I did quite some work on this last year, but had no time to
finish it. I still have no time for finishing, but I should be able to
hand-over my results (including prepared patches for Python 3.7).

Rational for GUIX_PYTHONPATH being a cludge (IMHO)

- Constraint: We must keep the expected behavior of PYTHONPATH as
documented for CPython. This esp. means, we must not simply substitute
in the source PYTHON_PATH by GUIX_PYTHONPATH, but need to *add* code.

- When implementing GUIX_PYTHONPATH in site.py or site-cutomize.py, it
will fail if python is run using -S (disable the import of the module
site, and thus site-customize).

- When implementing GUIX_PYTHONPATH in getpath.c, we need to copy the
current code for PYTHONPATH, which means we will end up with a not so
short patch. And even then, this special care needs to be taken to not
leak GUIX_PYTHONPATH from one profile to the other.

- We still need a wrapper (which caused a lot of problems, we already
solve. But maybe other problem will arise).

- If patching getpath.c anyway, we could go for interpreter to determine
the correct "installation path" (see above).

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Down with PYTHONPATH!

[Ricardo Wurmus]

Hi Hartmut,

>> here’s a half-baked idea that I think is worth considering: let’s patch
>> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
>> our wrappers.
>
> I have a *strong* opinion against this, as this would just replace one
> cludge by another one. See below for rational.
>
> IMO the only sustainable solution it to patch the interpreter
> (Modules/getpath.c) to determine the correct "installation path"
> (profile). I did quite some work on this last year, but had no time to
> finish it. I still have no time for finishing, but I should be able to
> hand-over my results (including prepared patches for Python 3.7).

This seems like a much bigger change that would require extensive
testing as it aims to get rid of the wrappers as well.  I welcome a
solution that allows us to ditch the wrappers, but I’d like to fix this
large set of our Python problems soon.

GUIX_PYTHON2PATH / GUIX_PYTHON3PATH is as solution that’s really just a
variant of what we’ve been doing all along (with PYTHONPATH), and it has
precedent in GUIX_LOCPATH, GUIX_GTK2_IM_MODULE_FILE, and
GUIX_GTK3_IM_MODULE_FILE.  It’s a simple solution and removing it later
when a better solution comes along has virtually no costs.

> Rational for GUIX_PYTHONPATH being a cludge (IMHO)

Of course it isn’t pretty.  But introducing it will remove a very real
problem we have.  Installing a package via Guix should not affect other
software that may be available on the system.  Setting PYTHONPATH (to
tell the Guix Python where to find modules the user has installed)
unexpectedly violates this assumption.

GUIX_PYTHONPATH (like GUIX_LOCPATH, GUIX_GTK2_IM_MODULE_FILE and
GUIX_GTK3_IM_MODULE_FILE before it) has the potential to fix this with
relatively little effort.

> - Constraint: We must keep the expected behavior of PYTHONPATH as
> documented for CPython. This esp. means, we must not simply substitute
> in the source PYTHON_PATH by GUIX_PYTHONPATH, but need to *add* code.
>
> - When implementing GUIX_PYTHONPATH in site.py or site-cutomize.py, it
> will fail if python is run using -S (disable the import of the module
> site, and thus site-customize).

I would not implement it there but do it in CPython, copying whatever
code there is for PYTHONPATH and adapt it for GUIX_PYTHONPATH.

> - When implementing GUIX_PYTHONPATH in getpath.c, we need to copy the
> current code for PYTHONPATH, which means we will end up with a not so
> short patch. And even then, this special care needs to be taken to not
> leak GUIX_PYTHONPATH from one profile to the other.
>
> - We still need a wrapper (which caused a lot of problems, we already
> solve. But maybe other problem will arise).

This is a separate problem and it is not a new problem introduced by
GUIX_PYTHONPATH.  We have already simplified the use of wrappers for
scripting languages on core-updates (using a polyglottal Guile wrapper).

--
Ricardo

Re: Down with PYTHONPATH!

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> Nowadays, in the wider world (beyond Guix), PYTHONPATH is mainly a
> newbie trap. Experienced pythonistas have abandoned it for virtual
> environments. So if it can be turned into a mechanism for supporting
> Guix environments with a name change, I doubt anyone would complain
> about standard PYTHONPATH being gone.

How does virtualenv work, if not by setting PYTHONPATH?

Setting up an environment all about augmenting the search path, so I
naively thought that virtualenv sets PYTHONPATH or the corresponding
Python variable.

Thanks,
Ludo’.

Re: Down with PYTHONPATH!

[Ludovic Courtès]

Hello,

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> IMO the only sustainable solution it to patch the interpreter
> (Modules/getpath.c) to determine the correct "installation path"
> (profile). I did quite some work on this last year, but had no time to
> finish it. I still have no time for finishing, but I should be able to
> hand-over my results (including prepared patches for Python 3.7).

So the interpreter would somehow have to determine where what profile
it’s in (if any), like ‘current-profile’ in (guix describe) does?

Note that python would still have to run even when it’s not running from
a profile.

Ricardo Wurmus <rekado@elephly.net> skribis:

> GUIX_PYTHON2PATH / GUIX_PYTHON3PATH is as solution that’s really just a
> variant of what we’ve been doing all along (with PYTHONPATH), and it has
> precedent in GUIX_LOCPATH, GUIX_GTK2_IM_MODULE_FILE, and
> GUIX_GTK3_IM_MODULE_FILE.  It’s a simple solution and removing it later
> when a better solution comes along has virtually no costs.

I agree… except for using the argument of there being a precedent,
because these were not solutions we were particularly proud of I think.
:-)

Thanks,
Ludo’.

Re: Down with PYTHONPATH!

[Konrad Hinsen]

Hi Ludo,

> How does virtualenv work, if not by setting PYTHONPATH?

It creates a new filetree corresponding to a complete new Python
installation, and the uses soft links to share most of the actual files
with the parent installation.

> Setting up an environment all about augmenting the search path, so I
> naively thought that virtualenv sets PYTHONPATH or the corresponding
> Python variable.

PYTHONPATH only adds directories to the search path. The standard
library and packages installed via pip are already on the search path
before PYTHONPATH is looked at. So virtualenv could not work by
modifying PYTHONPATH.

Konrad.

Re: Down with PYTHONPATH!

[Hartmut Goebel]

Am 17.06.19 um 11:03 schrieb Ludovic Courtès:
> How does virtualenv work, if not by setting PYTHONPATH?

Appending to Konrads answer: Making the profile a fake virtualenv does
not work. See my analysis part 2
(50179a9a-4e29-e729-ee49-ccbb90d9eda9@crazy-compilers.com).

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Down with PYTHONPATH!

[Pjotr Prins]

On Mon, Jun 17, 2019 at 12:20:12PM +0200, Konrad Hinsen wrote:
> Hi Ludo,
> 
> > How does virtualenv work, if not by setting PYTHONPATH?
> 
> It creates a new filetree corresponding to a complete new Python
> installation, and the uses soft links to share most of the actual files
> with the parent installation.

Exactly, Python is 'aware' of certain default paths. Virtualenv uses
that.

> > Setting up an environment all about augmenting the search path, so I
> > naively thought that virtualenv sets PYTHONPATH or the corresponding
> > Python variable.
> 
> PYTHONPATH only adds directories to the search path. The standard
> library and packages installed via pip are already on the search path
> before PYTHONPATH is looked at. So virtualenv could not work by
> modifying PYTHONPATH.

PYTHONPATH's main use is to override the search path for modules. Guix
using this is a recipe for trouble because users will always want to
set it for their own purposes (I do the same for the genenetwork
stack) and you get the question of precedence and versioning - I solve
it by creating a module library that makes use of a Guix hash so it is
tied to one interpreter.

We should always allow people to override PYTHONPATH.

For Guix it would actually make sense to make the interpreter Guix
aware. Since we don't abide by the default paths I think it takes very
much approach similar to overriding RPATH to solve this satisfactory.

That does imply patching the interpreter. All interpreters, including
Ruby and Perl. A special environment variable may work too.

It would be interesting to see how others solve this problem.
Including Nix and Conda.

Pj.

Re: Down with PYTHONPATH!

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

>> GUIX_PYTHON2PATH / GUIX_PYTHON3PATH is as solution that’s really just a
>> variant of what we’ve been doing all along (with PYTHONPATH), and it has
>> precedent in GUIX_LOCPATH, GUIX_GTK2_IM_MODULE_FILE, and
>> GUIX_GTK3_IM_MODULE_FILE.  It’s a simple solution and removing it later
>> when a better solution comes along has virtually no costs.
>
> I agree… except for using the argument of there being a precedent,
> because these were not solutions we were particularly proud of I think.
> :-)

Yes, those solutions aren’t pretty but they are well understood and have
no surprising behaviour, which is what I meant.  GUIX_PYTHON2/3PATH
would be a boring solution that works just like the others I listed.

--
Ricardo

Re: Down with PYTHONPATH!

[Hartmut Goebel]

Am 17.06.19 um 20:34 schrieb Ricardo Wurmus:
> Yes, those solutions aren’t pretty but they are well understood and have
> no surprising behaviour, which is what I meant.  GUIX_PYTHON2/3PATH
> would be a boring solution that works just like the others I listed.

TL;DR: Got for GUIX_PYTHONPATH_3_7.

Sorry, last weekend I did not find the time to pick up my last year's
work and prepare a hand-over. Not sure if I will make it this month
(given I'll be off some days). So just a quick answer:

1) Using some GUIX_PYTHONPATH is an improvement to the current situation
and could be implemented quickly.

If this variable is going to be exposed to the user's environment (say:
used outside of wrapper scripts), I suggest including the version into
the name: e.g. GUIX_PYTHONPATH_3_7. Otherwise one will still get
conflicts if one has installed Python 3.5, 3.6 and 3.8 in the same
environment. (Yes, this is a common case for developers.)

2a) My plan is to make the python executable aware of its "home"
("installation directory", the profile) without using any environment
variable. python already does this (by resolving all symlinks), we just
need to adopt this to stop at the profile. This should bea eay to
implement, I have a draft ready but need to prepare the hand-over.

2b) Another idea is to change the build-system to leverage virtualenvs
for Python scripts/apps/tools. This would not only remove the need for
wrappers, but should also solve conflicts if a script requires a
different versions of packages than installed in the profile.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Down with PYTHONPATH!

[Konrad Hinsen]

Hi Pjotr,

> It would be interesting to see how others solve this problem.
> Including Nix and Conda.

Conda uses the same approach as Python's virtualenv: create a seperate
Python installation made up mainly of linke to files shared with other
such installations.

We could probably do something similar in Guix as well, assuming we can
make the Python executable figure out from which environment it was
started.

Konrad

Re: Down with PYTHONPATH!

[Hartmut Goebel]

Am 18.06.19 um 17:46 schrieb Konrad Hinsen:
> Conda uses the same approach as Python's virtualenv: create a seperate
> Python installation made up mainly of linke to files shared with other
> such installations.
>
> We could probably do something similar in Guix as well, assuming we can
> make the Python executable figure out from which environment it was
> started.

This is my plan, see my yesterday's mail:
0cf6e747-48b5-1606-28a0-02fd4d37086a@crazy-compilers.com

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Down with PYTHONPATH!

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 991 bytes --]

Hallo Ricardo,

ich wollte meine Fäden zu diesem Thema wieder aufnehmen und meine
bisherigen Erkenntnisse so zusammenstellen, dass jmd. anderes auch etwas
damit anfangen kann (und ich kein Flaschenhals bin).

Da ich mich seit 1 Jahr nicht mehr richtige damit beschäftigt habe,
scheitere ich an einem ganz doofen Punkt:

Für welche Fälle wird PYTHONPATH eigentlich gesetzt - sprich für welche
Fälle brauchen wir eine Lösung?

 1. guix environment --ad-hoc python: NEIN, da das environment
    "komplett" ist
 2. guix package -i python: JA, python ein symlink in den store ist,
    aber "site-packages" aus dem profile kommen sollen (PYTHONPATH wird
    in "$GUIX_PROFILE/etc/profile" gesetzt
 3. python Anwendungen (z.B. pdfposter): JA, im Wrapper

Habe ich Fälle übersehen?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Down with PYTHONPATH!

[Pjotr Prins]

On Sat, Jul 06, 2019 at 12:45:19PM +0200, Hartmut Goebel wrote:
> Hallo Ricardo,
> 
> ich wollte meine Fäden zu diesem Thema wieder aufnehmen und meine
> bisherigen Erkenntnisse so zusammenstellen, dass jmd. anderes auch etwas
> damit anfangen kann (und ich kein Flaschenhals bin).
> 
> Da ich mich seit 1 Jahr nicht mehr richtige damit beschäftigt habe,
> scheitere ich an einem ganz doofen Punkt:
> 
> Für welche Fälle wird PYTHONPATH eigentlich gesetzt - sprich für welche
> Fälle brauchen wir eine Lösung?
> 
>  1. guix environment --ad-hoc python: NEIN, da das environment
>     "komplett" ist
>  2. guix package -i python: JA, python ein symlink in den store ist,
>     aber "site-packages" aus dem profile kommen sollen (PYTHONPATH wird
>     in "$GUIX_PROFILE/etc/profile" gesetzt
>  3. python Anwendungen (z.B. pdfposter): JA, im Wrapper
> 
> Habe ich Fälle übersehen?

Very punk message. I like it :)

> -- 
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel          | h.goebel@crazy-compilers.com               |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 
> 

Re: Down with PYTHONPATH!

[Ricardo Wurmus]

Hi Hartmut,

> Für welche Fälle wird PYTHONPATH eigentlich gesetzt - sprich für welche
> Fälle brauchen wir eine Lösung?
>
>  1. guix environment --ad-hoc python: NEIN, da das environment
>     "komplett" ist

We set PYTHONPATH here, because the search path is attached to the
“python” package.  It is not needed here, but that’s how the search path
mechanism works in Guix.

>  2. guix package -i python: JA, python ein symlink in den store ist,
>     aber "site-packages" aus dem profile kommen sollen (PYTHONPATH wird
>     in "$GUIX_PROFILE/etc/profile" gesetzt

This is the same case as above.  In both cases a profile is generated
and PYTHONPATH is set since the “python” package contains a search path
definition for PYTHONPATH.

It is not set if only a Python module is installed without “python”
itself.  Installing, for example, only “python-numpy” without also
installing “python” won’t lead to a definition of PYTHONPATH.

>  3. python Anwendungen (z.B. pdfposter): JA, im Wrapper

Here we set PYTHONPATH in a wrapper script during a standard build phase
of the python-build-system.  (We can use wrap-script once core-updates
is merged to use a Guile wrapper in the very same file.)

So, there really are only two cases where we set PYTHONPATH: in profiles
due to the search-path property on “python” itself, and in wrapper
scripts.

It is conceivable to have both cases happen at the same time: installing
a Python application (or a library that also includes an executable)
together with “python” into a profile would lead to having the
application wrapped in PYTHONPATH at build time and it would set
PYTHONPATH (e.g. by adding it to the profile’s etc/profile) because
“python” is installed.

--
Ricardo