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

Jim J. Jewett jimjjewett at gmail.com
Wed Mar 14 15:53:48 CET 2012

In view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html van.lindberg at gmail.com posted:

1) The layout for the python root directory for all platforms should be as follows:

stdlib = {base/userbase}/lib/python{pyversionshort} platstdlib = {base/userbase}/lib/python{pyversionshort} purelib = {base/userbase}/lib/python{pyversionshort}/site-packages platlib = {base/userbase}/lib/python{pyversionshort}/site-packages include = {base/userbase}/include/python{pyversionshort} scripts = {base/userbase}/bin data = {base/userbase}

Why?

Pure python vs compiled C doesn't need to be separated at the directory level, except for cleanliness.

Some (generally unix) systems prefer to split the libraries into several additional pieces depending on CPU architecture.

The structure listed above doesn't have a location for docs.

Some packages (such as tcl) may be better off in their own area.

What is "data"? Is this an extra split compared to today, or does it refer to things like LICENSE.txt, README.txt, and NEWS.txt?

And even once I figure out where files have moved, and assume that the split is perfect -- what does this buy me over the current situation? I was under the impression that programs like distutils already handled finding the appropriate directories for a program; if you're rewriting that logic, you're just asking for bugs on a strange platform that you don't use.

If you're looking for things interactively, then platform conventions are probably more important than consistency across platforms. If you disagree, you are welcome to reorganize your personal linux installation so that it matches windows, and see whether it causes you any problems.

... We already have this. The only difference in this proposal is that we go from pyversionnodot to pyversionshort, i.e. from

c:\python33\lib\python33

to

c:\python33\lib\python3.3

I have not seen that redundancy before on windows.

I'm pretty sure that it is a relic of your Linux provider wanting to support multiple python versions using shared filesystems. The Windows standard is to use a local disk, and to bundle it all up into its own directory, similar to the way that java apps sometimes ship with their own JVM.

Also note that using the dot in a directory name is incautious. I haven't personally had trouble in several years, but doing so is odd enough that some should be expected. Python already causes some grief by not installing in "Program Files", but that is at least justified by the "spaces in filenames" problem; what is the advantange of 3.3?

I'm using windows, and I just followed the defaults at installation. It is possible that the installer continued to do something based on an earlier installation, but I don't think this machine has ever had a customized installation of any python version.

C:\python32* Everything is under here; I assume {base/userbase} would be set to C:\python32

As is customary for windows, the base directory contains the
license/readme/news and all executables that the user is
expected to use directly.  (python.exe, pythonw.exe.  It also
contains w9xpopen.exe that users do not use, but that too is
fairly common.)

There is no data directory.

Subdirectories are:

C:\python32\DLLs In additional to regular DLL files, it contains .pyd files and icons. It looks like modules from the stdlib that happen to be written in C. Most users will never bother to look here.

C:\python32\Doc A .chm file; full html would be fine too, but removing it would be a bad idea.

C:\python32\include These are the header files, though most users will never have any use for them, as there isn't generally a compiler.

C:\python32\Lib The standard library -- or at least the portion implemented in python.

Note that site-packages is a subdirectory here.  It doesn't
happen to have an __init__.py, but to an ordinary user it
looks just like any other stdlib package, such as xml or
multiprocessing.

I personally happen to keep things in subdirectories of
site-packages, but I can't say what is standard.

Moving site-packages out of the Lib directory might make
sense, but probably isn't worth the backward compatibility hit.

C:\python32\libs .lib files. I'm not entirely sure what these (as opposed to the DLLs) are for; lib files aren't that common on windows. My machine does not appear to have any that aren't associated with cross-platform tools or unix emulation.

C:\python32\tcl Note that this is in addition to associated files under DLLs and libs. I would prefer to see them in one place, but moving it in with non-tcl stuff would not be an improvement. Most users will never look (or care); those that do usually appreciate knowing that, for example, the dde subdirectory is for tcl.

C:\python32\Tools This has three subdirectories (i18n, pynche, Scripts).

Moving the .py files in with the binary just because you could
execute them using file associations would be a step backwards;
you can do the same regardless of where they are.

-jJ

--

If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ

More information about the Python-Dev mailing list