Skip to content
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

PYTHONPATH not honored (not even for sub-interpreters) #16

Open
eudoxos opened this issue Apr 13, 2022 · 4 comments
Open

PYTHONPATH not honored (not even for sub-interpreters) #16

eudoxos opened this issue Apr 13, 2022 · 4 comments
Labels
bug Something isn't working

Comments

@eudoxos
Copy link

eudoxos commented Apr 13, 2022

I am trying to run python interpreter with modified sys.path. This is normally done by setting the PYTHONPATH environment variable. I understand wenv cannot do this due to path translation when called from Linux shell:

$ PYTHONPATH=foo:bar python -c'import sys; print(sys.path)'
['', '/home/eudoxos/foo', '/home/eudoxos/bar', '/usr/lib/python310.zip', '/usr/lib/python3.10', # .... 
$ PYTHONPATH='foo;bar' wenv python -c'import sys; print(sys.path)'
['C:\\python-3.8.5.stable\\Lib', 'C:\\python-3.8.5.stable', 'C:\\python-3.8.5.stable\\lib\\site-packages']
# where is foo and bar?

But now I have a script running under wenv, which runs a child python process, wanthing to pass it some paths through its environment PYTHONPATH. This work both under Linux and under Windows, but not under wenv. The one-liner is like this (explanation: the main python calls another python as subprocess, passing it PYTHONPATH through an argument to subprocess.call):

$ wenv python -c "import sys, subprocess; subprocess.call([sys.executable,'-c','import sys; print(sys.path)'],env={'PYTHONPATH':'foo;bar'})"
['C:\\python-3.8.5.stable\\Lib', 'C:\\python-3.8.5.stable', 'C:\\python-3.8.5.stable\\lib\\site-packages']
# where is foo and bar?

As I checked, sys.executable is correct in the main interpreter:

$ wenv python -c'import sys; print(sys.executable)'
C:\python-3.8.5.stable\python.exe

Any ideas?

@s-m-e
Copy link
Member

s-m-e commented Apr 13, 2022

That's an interesting one ... I extended your second to last test a bit and switched to Popen. Still the same. But ...

wenv python -c "import sys, subprocess; p=subprocess.Popen([sys.executable,'-c','import sys, os; print(sys.path); print(os.environ)'],env={'PYTHONPATH':'foo;bar', 'BARFOO': 'FOOBAR'}); p.wait()"

... the two variables are clearly passed on: environ({'PYTHONPATH': 'foo;bar', 'BARFOO': 'FOOBAR', [...].

This behavior has its origin in the fact that wenv uses an embedded Python interpreter, which tends to have some odd edge cases in path handling. I am working around this using a pth-file. If you remove this file, your code works as expected.

I forgot the full backstory of the pth-file - i.e. why I needed it in the first place - and I did not put it into the comments. My mistake. I'll to trace the commit(s) back. It was once part of another package, zugbruecke, and I believe that some tests were not working without this hack.

@s-m-e s-m-e added the bug Something isn't working label Apr 13, 2022
@s-m-e
Copy link
Member

s-m-e commented Apr 14, 2022

This was an issue with coverage (not) running under wenv python, see here. This was a long time ago - maybe I can get rid of it now.

@eudoxos
Copy link
Author

eudoxos commented Apr 25, 2022

For our use-case, it would be sufficient to override PYTHONPATH via wenv.json. Is that possible?

@s-m-e
Copy link
Member

s-m-e commented Apr 25, 2022

@eudoxos I need to look into if (how) this is possible. In the meantime, have you tried deleting the pth file? It's located in your virtual environment under share/wenv/winX/drive_c/python-3.Y.Z.stable/python3Y._pth. It gets created during wenv init so you can delete it in your CI pipeline in a subsequently triggered command. X is either 32 or 64. Y and Z are the Wine Python's minor and micro versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants