[Python-Dev] First draft of "sysconfig"

[Tarek Ziadé]

2009/12/14 Dino Viehland <dinov at microsoft.com>:
[..]
> 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".
>

Right that's a small bug in the refactoring (there's an extra /) but
there will be a bit of redundancy
on "Python", at the end nevertheless:

The base directory in win32 for the user scheme in is :

APPDATA *or* ~/Python

(under linux it's ~/.local)

then various subdirectories are added in that directory, and some of
them starts with "PythonXY", like:

~/Python/Python26/..

See http://www.python.org/dev/peps/pep-0370/#specification


> 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).

Yes that's one point someone raised (can't recall who) and the idea was to
have a separate top directory for user dirs, that would start with the name
of the implementation:

so for Windows:

~/Python/Python26/..
~/IronPython/../
~/Jython/../

and for Linux and al, I am not sure but maybe a prefix for
Jython/etc.. could be used
for all paths.

~/.locale/lib/python/2.6/site-packages/...
~/.locale/jython/lib/python/2.6/site-packages/...

(I didn't digg on how Jython organizes things yet, any hint would be
appreciated)

>
>> * 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.

Ok so it sounds like it would be easier to cook that value in a built-in in each
implementation,

>
> 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.

So like, having an architecture marker, that defaults to the current ?

   get_platform(architecture=platform.architecture)

Regards
Tarek

-- 
Tarek Ziadé | http://ziade.org