[Python-Dev] First draft of "sysconfig"

[Dino Viehland]

Tarek wrote:
> == Installation schemes ==
> 
> First, the module contains the installation schemes for each platform
> CPython uses.
> An install scheme is a mapping where the key is the "code" name for a
> directory, and
> the value the path of that directory, with some $variable that can be
> expanded.
> 
> Install schemes are stored in a private mapping, where the keys are
> usually the value of os.name,
> and the value, the mapping I've mentionned earlier.
> 
> So, for example, the paths for win32 are:
> 
> _INSTALL_SCHEMES = {
>   ...
>   'nt': {
>         'stdlib': '$base/Lib',
>         'platstdlib': '$base/Lib',
>         'purelib': '$base/Lib/site-packages',
>         'platlib': '$base/Lib/site-packages',
>         'include': '$base/include',
>         'platinclude': '$base/include',
>         'scripts': '$base/Scripts',
>         'data'   : '$base',
>         },
>   ...
> }

Not mentioned here are the user schemes.  Looking at the code it seems that
_getuserbase is adding "Python" to the path on nt.  Isn't that redundant?
The paths in _INSTALL_SCHEMES already include "Python".

Also w/ user dirs in general - I think there should be some implementation 
specific portion of the path as well.  Right now I think IronPython and 
CPython will end up with the same user paths for the same versions which 
could cause problems if someone releases separate modules for IronPython
and CPython for some reason (or if users just want different sets of
things installed for different interpreters).

> * get_platform():  Return a string that identifies the current
> platform. (this one is used by site.py for example)

I wonder if this would make more sense a built-in.  Ultimately it seems 
like the interpreter implementation knows best about what aspects of
it's underlying platform would require different libraries.

With the existing code I think IronPython would return "cli" everywhere 
(because os.name == 'nt' on Windows but posix on Linux & Mac OS/X but 
we still don't have uname).  I think Jython will return something like 
java1.6.0_17 because it's os.name is java - which might be more specific
than is necessary.  

Also if the purpose of this is for platform specific build directories
it might be interesting to have multiple return values.  For example in
IronPython the minimal thing we'd want I think is a "cli" directory for
.NET assemblies.  But there could also be native extensions which are
platform specific so we'd want "cli-x86" and "cli-x64" depending upon
the platform.  Jython might want the same thing as they add ctypes
support.