[Python-Dev] Python install layout and the PATH on win32 (original) (raw)

Mark Hammond mhammond at skippinet.com.au
Wed Mar 14 23:39:53 CET 2012

On 15/03/2012 3:03 AM, Lindberg, Van wrote:

On 3/14/2012 1:32 AM, Mark Hammond wrote:

As per comments later in the thread, I'm -1 on including "python{pyversionshort}" in the lib directories for a number of reasons; one further reason not outlined is that it would potentially make running Python directly from a built tree difficult. For the same reason, I'm also -1 on having that in the include dir. A built tree would look the same as always - the directories would only be moved (if at all) during installation. Thus, you will still be able to run python directly from a built installation.

So long as the location of the "lib" dir doesn't change, that is probably true. If lib was to change though, then PC/getpathp.c would need to change which is where my concern came from.

scripts = {base/userbase}/bin

We should note that this may cause pain for a number of projects - I've seen quite a few projects that already assume "Scripts" on Windows - eg, virtualenv and setuptools IIRC If you look at these projects, though, they special case Windows to account for the different layout. Removing this difference will allow these projects to remove their special-casing code.

I don't think that is true. One of the examples I offered was a .bat file - it wouldn't be possible to remove the .bat file with your proposal. The other example was the Windows specific launcher.

Most things that need to locate the Python executable aren't actually Python code - once Python is running, locating the executable is as simple as sys.executable. So by their very nature, tools needing to locate Python will tend to be platform specific in the first place.

Can you offer any examples of 3rd party tools which could unify code in this scheme, and particularly, where this scheme would cause them to have less code, not more?

- and also assume the executable is where it currently lives - one example off the top of my head is the mozilla "jetpack" project - see:

https://github.com/mozilla/addon-sdk/blob/master/bin/activate.bat#L117 This code actually reinforces my point: First, this code would actually still work. The section ":FoundPython" sets the PATH to "%VIRTUALENV%\bin;%PYTHONINSTALL%;%PATH%" (L80), which would still allow python.exe to be found and run. Second, look at that line again. Mozilla actually has edited this code so that the jetpack uses a cross-platform "bin" convention, just as I am proposing.

I think you misunderstand the .bat file - there is no python executable in the bin directory. The bat file is locating your already installed Python and attempting to use it.

Third, one element of this proposal is that there would be a key placed in the registry that points directly to the location of the python executable, making locating it trivial to locate programmatically on Windows.

That sounds reasonable, but it still causes breakage, and still causes extra code for tools needing to support earlier versions. Saying "hey, it's easy to fix" are just words to someone frustrated trying to get things working with a later version of Python.

Don't get me wrong - the scheme you propose is how it should have been done in the first place, no question. My issue is the breakage this will cause versus the benefit.

My other questions still remain: who specifically will benefit from this, and what would be the cost to those beneficiaries of sticking with the existing scheme? The only benefit I've seen suggested is aesthetics, and while that is laudable, I don't think it is enough to justify breakage.

Cheers,

Mark

More information about the Python-Dev mailing list