= phenomenon = People use custom Python builds setting PYTHONHOME and PYTHONPATH to these custom builds. This may be expected to break running system Python binary but it also unexpectedly breaks standard Fedora applications: {{{ $ echo foo >site.py; export PYTHONPATH=. $ gdb Traceback (most recent call last): File "./site.py", line 1, in <module> foo NameError: name 'foo' is not defined $ _ }}}
It is not obvious to the user who even already forgot about custom PYTHONPATH why GDB breaks.
= reason = Standard Fedora applications may link with system libpython incompatible with the PYTHONHOME/PYTHONPATH files for the other Python version. Python does not keep the scripts too compatible across Python versions.
= recommendation = This issues was discussed first for GDB upstream: [RFA] ignore PYTHONHOME environment variable. [http://sourceware.org/ml/gdb-patches/2010-11/msg00328.html 2010-11] [http://sourceware.org/ml/gdb-patches/2010-12/msg00214.html 2010-12] [http://sourceware.org/ml/gdb-patches/2011-01/msg00307.html 2011-01] [http://sourceware.org/ml/gdb-patches/2012-05/msg00710.html 2012-05] (first mail of the thread in each month)
But exactly the same problem exists for many other apps, yum for all {{{ $ echo foo >site.py; PYTHONPATH=. yum list bash Traceback (most recent call last): File "./site.py", line 1, in <module> foo NameError: name 'foo' is not defined $ _ }}}
Various proposal have been, applicable possibly in some combination together: Ignore PYTHONHOME, use only GDB_PYTHONHOME (if set). This proposal is not applicable for all applications in general. Print warning if PYTHONHOME/PYTHONPATH is set. Recover from Python startup failure and suppress the environment vars. or Recover from Python startup failure and disable the Python support, if possible. Should the special care affect PYTHONHOME? Differently for PYTHONPATH? What about PYTHONVERBOSE and other PYTHON settings?
How should get PYTHONHOME/PYTHONPATH inherited into child processes, if any (debuggees in the GDB case).
Another question is whether the behavior should be the same if upstream application has been linked with non-system libpython location. But that is seems out of the FESCo scope, just FYI.
What change are you asking for?
To make packaging rule from some combination of the items listed above.
Something like for example - I do not try to suggest this specific decision:[[BR]] If application is using libpython and it is not the {{{python}}} binary itself: * Print warning if PYTHONHOME/PYTHONPATH is set. * Print visible message about unsetting PYTHONHOME/PYTHONPATH if Python startup fails.
At a first glance, how is this different from someone setting LD_LIBRARY_PATH to a directory with a nonsensical file named libc.so.6? In general, we can't protect the system from every possible way how the user can break the system.
OTOH, users do actually run their own Python implementations, so...
I don't know.
It "should" be possible for users to run their own Python implementations, and asking all Fedora applications written in Python to run (python -E) to ignore the environment, and all Fedora applications that embed the Python runtime to do something similar doesn't sound all that crazy. It would mean that users can only affect the environment of system applications by changing the system, which sort of makes sense (especially in presence of the various "stack" efforts), but is sure to breaks someone's workflow. Also, the change to -E is rather a lot of work given the size of the distribution given.
As for the other proposed alternatives - GDB_PYTHONHOME is, I think, up to gdb upstream and/or maintainers, and the others don't seem too attractive to me: * Mandating warnings doesn't make much sense - if the user needs to have the variable set up, the warning will primarily be annoying (either it is unnecessary, or the user will ask why doesn't the application ignore the variable). * Silently recovering is not possible for applications written in Python (without wrapping all of the application in a separate script), and it would be probably just as unexpected as the original dependence on PYTHONHOME.
I (also) find the current behavior correct but from upstream GDB discussion and now repeatedly off-list Fedora GDB complaint I see the current GDB behavior may not fit the users.
As I do not use Python myself and I find the problem unspecific to GDB I have filed this ticket.
Replying to [comment:2 jankratochvil]:
To make packaging rule from some combination of the items listed above. Sounds like an FPC issue, then, not FESCo. Something like for example - I do not try to suggest this specific decision:[[BR]] If application is using libpython and it is not the {{{python}}} binary itself: * Print warning if PYTHONHOME/PYTHONPATH is set. * Print visible message about unsetting PYTHONHOME/PYTHONPATH if Python startup fails.
Sounds like an FPC issue, then, not FESCo.
FWIW, I'd be against this. It seems more like something that should get incorporated into upstream python than be done at the distro level. It could, however, take the form of a PEP (Informational) that advises application authors about proper use of python environment variables. With that sort of thing we (and other distros) could submit patches to upstream applications to make changes to follow the PEP's advice.
As a developer who uses python I can see that this is a valid approach to the problem but I'm not sure it should be general (and therefore emit a warning whenever used in this manner). For instance, mod_wsgi links to libpython but it is embedding a python interpreter in apache to run python applications in much the same way that /usr/bin/python itself does. vim links to libpython to give users access to python to write vim macros and plugins. A user would expect to be able to use PYTHONHOME and PYTHONPATH to affect the python modules that are available to their scripts.
When people use local installation of their favourite language, they should properly set their environment. I would prefer upstream solution.
People use custom Python builds setting PYTHONHOME and PYTHONPATH to these custom builds. Why are they setting PYTHONHOME and PYTHONPATH? This shouldn't be necessary for a custom build of Python.
Replying to [comment:7 dmalcolm]:
Why are they setting PYTHONHOME and PYTHONPATH? This shouldn't be necessary for a custom build of Python.
I guess they transfer binaries across hosts, maybe.
Thanks for the feedback, therefore moved it upstream: http://bugs.python.org/issue14956
Login to comment on this ticket.