PEP 250 - site-packages on Windows: (Was: [Distutils] Package DB: strawman PEP)

[Robin Becker]

In article <714DFA46B9BBD0119CD000805FC1F53B01B5AEDF@ukrux002.rundc.uk.o
rigin-it.com>, Moore, Paul <Paul.Moore@atosorigin.com> writes
>From: Pete Shinners [mailto:pete@shinners.org]
>> for the love of all things good, can we please make a recommendation
>> in our PEP that the windows installation location be something other
>> than "C:\PYTHON21"? something like "C:\PYTHON21\SITE-PACKAGES" would
>> be a big improvement. i thought i heard that macpython recently made
>> this "fix", why is the windows version lagging on this?
>
>PEP 250 covers this. I have sent in the final PEP for approval, plus a
>patch, but the process appears to be stalled. I guess I need to nag again.
>The PEP process doesn't seem to cover non-core Python developers well (eg,
>people like me who don't have a way of integrating with the Sourceforge
>mechanisms...)
>
>Paul.
...
does this PEP address the location of .pyds and associated .dlls under
win32?

If I have several separate extensions which depend on common .dlls there
is always a problem under win32 if they go into separate areas. As I
understand it if the dll is in the same directory as the pyd that uses
it then all's well.

I have no objection to dlls and .dlls ending up in PYTHONROOT\lib\site-
packages, but what about the associated .libs (for dlls/pyds) and real
static .libs and where are we to install include files for exported
apis. I haven't any objection to following the unix model as closely as
possible, but what really stands out here is that the base install has
its own special directories for DLLs and Libs etc. The extensions are
really just extensions and could theoretically be installed or not.
-- 
Robin Becker