New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
custom PYTHONPATH may break apps embedding Python #59161
Comments
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 various applications which also embed Python: $ 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. 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. This issues was discussed first for GDB upstream: 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:
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. |
An alternate idea would be to recommend more strongly in the doc that people should not shadow standard library module names (in your example, site). |
This site.py is only an example how it can happen. In reality it is due to .py files intended for incompatible version of Python. I am not a Python programmer to have some appropriate incompatible code at hand. |
|
I think it is up to each embedding application to decide if it wants to respect the environment variables or not. I don't think that's a decision that core can make. Now, if we aren't providing an easy way for an embedding application to make that decision, that might be something we could fix. But I suspect we are (I don't know the C API well enough to say for sure). |
I fully agree with site.py/os.py/spam.py but I find it offtopic for this Issue. I do not find too important if some unsetenv/setenv gets called by the app or by libpython. But the rules should apply for every embedded app the same, the Fedora ticket is suggesting new PEP (Informational) for it. |
An informational PEP sounds like exactly what I said: each application needs to decide. The PEP would provide the information on which to base that decision, and suggestions for how to do it. An informational PEP on best practices for embedding sounds like a great idea to me. I hope someone will write one. |
It wouldn't be a PEP, it would be an addition to the embedding docs: |
For the more general breakage due to PYTHONHOME and PYTHONPATH, yeah, global environment variables are bad, particularly when an OS relies on tools written in (or embedding) Python. That's the reason virtualenv (and 3.3's forthcoming venv) are a preferred alternative - they give you a space to play in that shouldn't break your system Python or apps that embed it. |
I don’t understand this message :) There is nothing to agree with or judge on or off-topic; I was trying to understand the root of the bug and really asking you in good faith to try two things to see if my idea was right. |
While it should be documented this is not only a docs issue. It should be solved in some way during runtime. |
No it shouldn't. As mentioned in the Fedora thread you linked, this is no different than the user setting LD_LIBRARY_PATH to something that screws up a system installed program. |
If we don't expose the mechanism behind -E to embedding applications via |
As far as I can tell, this issue is not resolved. It would be very nice for the C API to have the equivalent for -E for security reasons. I would like to make a setgid binary and do not want users to be able to set PYTHON* variables to force loading of custom code. |
Hi, Just updating this 6 year old bug report. The last comment says it's not possible to ignore environment when using the C-API. I don't know back then, but today it is possible. I have just built gdb 8.2 against python 3.7.1, and patched gdb with this simple patch, which apparently works: --- gdb/python/python.c + // Force using the toolchain python without being troubled by $PYTHONHOME or $PYTHONPATH.
+ Py_IgnoreEnvironmentFlag = 1;
+
Py_Initialize ();
PyEval_InitThreads (); Cheers, |
This issue has been fixed in 36763 by the PEP-587 which provides a new "Isolated Configuration" and a way to tune the Python configuration without impacting subprocesses. For example, the Isolated Configuration ignores environment variables by default. In Python 3.7 and older, you can set Py_IgnoreEnvironmentFlag to 1 (the flag exists also in Python 2.7), or even set Py_IsolatedFlag to 1 (new in Python 3.4). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: