[Python-Dev] Python install layout and the PATH on win32

[Jim J. Jewett]

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{py_version_short}
>>> platstdlib = {base/userbase}/lib/python{py_version_short}
>>> purelib = {base/userbase}/lib/python{py_version_short}/site-packages
>>> platlib = {base/userbase}/lib/python{py_version_short}/site-packages
>>> include = {base/userbase}/include/python{py_version_short}
>>> 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 py_version_nodot to py_version_short, 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