PEP: Use site-packages on all platforms

Paul Moore paul.moore at uk.origin-it.com
Mon Apr 2 10:31:28 EDT 2001


On Mon, 2 Apr 2001 11:29:44 +0200 , Robin Becker <robin at jessikat.fsnet.co.uk>
wrote:

>In article <mailman.985955621.21096.python-list at python.org>, Moore, Paul
><Paul.Moore at uk.origin-it.com> writes
>...
>If we're going to standardize locations I think it would be better for
>win32 platforms to use a single dlls directory either the current DLLs
>or lib/site-packages.
>
>That way the commonly used dlls (like libz.dll) could be placed in one
>standard location and then _imaging.pyd, zlib.pyd etc could refer to
>them. I'm not sure that this would work so well if there were two
>standard locations say DLLs for python only and lib/site-packages for
>everything else.
>
>Others have argued elsewhere that python20.dll needs to be in a common
>system wide location (ie winnt\system32 for similar reasons). 

python20.dll is in the system directory for the purposes of embedded Python
applications - the DLL search path is "the directory containing the current
EXE", then PATH, then the Windows and Windows System directories (roughly). So
the only place the installer can know is suitable even for embedding apps, is
one of the Windows directories (PATH is under the user's control, and so isn't
reliable, and the embedding app is probably not in the same place as
Python.exe, so the executable directory won't work).

The Python DLL sets the search path explicitly when it is loading modules, so
none of this applies there.

The separation of DLLs and Lib is (as far as I can see) for the purposes of
keeping binary extensions and "pure python" modules separate. On Unix, the
site-specific directories do this:

    .../lib/python2.0/site-packages    -- binaries
    .../lib/site-python                -- python

OK, this could be done on other platforms too. But that complicates things
further, to no particular advantage that I can see. (It's worth noting that in
2.1b2 for the Mac, the single site-packages directory approach I propose is
used). On Windows, complex structured installation directories like this are
not the norm.

My preference is to give the user one directory "of his own", but not to
propose any further structure.

I'd appreciate comments from users who embed Python - do strange things happen
with search paths in that case which might affect this?

Paul.




More information about the Python-list mailing list