Windows Python sys.prefix
Related to the issue I noted with sys.prefix on a Mac, moving the Python executable on Windows also doesn't seem to effect sys.prefix. How does Python on Windows determine sys.prefix? Is there a way to effect that? -- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers
How does Python on Windows determine sys.prefix?
By consulting the registry. The main use-case for that is when Python is embedded in another executable - often, but not always, via COM. When Python is hosted inside excel.exe, for example, its impossible to calculate sys.path or sys.prefix based on that executable. In that same example, Python's DLL will have been loaded from a directory on the global PATH, which generally means the \Windows\System32 directory - so that too is no help in calculating the path. [IIRC, Python actually tries to use the executable to locate its 'landmark' and only falls back to the registry when that fails - but that sounds exactly like what is happening in your example. The gory details are in PC/getpathp.c]
Is there a way to effect that?
Setting PYTHONHOME in the environment is the only way I'm aware of. Cheers, Mark
Mark Hammond wrote:
How does Python on Windows determine sys.prefix?
By consulting the registry. The main use-case for that is when Python is embedded in another executable - often, but not always, via COM. When Python is hosted inside excel.exe, for example, its impossible to calculate sys.path or sys.prefix based on that executable. In that same example, Python's DLL will have been loaded from a directory on the global PATH, which generally means the \Windows\System32 directory - so that too is no help in calculating the path.
[IIRC, Python actually tries to use the executable to locate its 'landmark' and only falls back to the registry when that fails - but that sounds exactly like what is happening in your example. The gory details are in PC/getpathp.c]
I can certainly create a landmark if at all reasonable. I'm looking at getpathp.c, and it looks like it just looks for lib/os.py ... and I think it walks up from the current directory until it finds it? So right now I have: bin/python.exe lib/python2.5/os.py But perhaps if I just change it to: bin/python.exe lib/os.py it will work? On windows, does it just leave out the "/python2.5/" portion of the lib path?
Is there a way to effect that?
Setting PYTHONHOME in the environment is the only way I'm aware of.
That's kind of what workingenv did, which I'm trying to avoid -- you have to worry about, for instance, calling another Python subprocess if you don't want that process to be in the same environment. -- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers
I can certainly create a landmark if at all reasonable. I'm looking at getpathp.c, and it looks like it just looks for lib/os.py ... and I think it walks up from the current directory until it finds it? So right now I have:
bin/python.exe lib/python2.5/os.py
But perhaps if I just change it to:
bin/python.exe lib/os.py
it will work?
Yep, and a quick test here works fine.
On windows, does it just leave out the "/python2.5/" portion of the lib path?
well - it doesn't "leave it out" as such - it just never adds anything like that :) Mark
After that and a bunch of other little updates, virtualenv (0.8.3) now works on Windows! Now it's just the blasted Mac Framework stuff that stops this from being a complete workingenv replacement. Mark Hammond wrote:
I can certainly create a landmark if at all reasonable. I'm looking at getpathp.c, and it looks like it just looks for lib/os.py ... and I think it walks up from the current directory until it finds it? So right now I have:
bin/python.exe lib/python2.5/os.py
But perhaps if I just change it to:
bin/python.exe lib/os.py
it will work?
Yep, and a quick test here works fine.
On windows, does it just leave out the "/python2.5/" portion of the lib path?
well - it doesn't "leave it out" as such - it just never adds anything like that :)
Mark
-- Ian Bicking : ianb@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers
In article <46F08E7C.4030001@colorstudy.com>, Ian Bicking <ianb@colorstudy.com> wrote:
Now it's just the blasted Mac Framework stuff that stops this from being a complete workingenv replacement.
It *might* help to move that discussion to the mac python list (a.k.a gmane.comp.python.apple). -- Ned Deily, nad@acm.org
participants (3)
-
Ian Bicking -
Mark Hammond -
Ned Deily