[Python-Dev] First draft of "sysconfig"
ziade.tarek at gmail.com
Mon Dec 14 23:58:08 CET 2009
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:
> 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:
and for Linux and al, I am not sure but maybe a prefix for
Jython/etc.. could be used
for all paths.
(I didn't digg on how Jython organizes things yet, any hint would be
>> * 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
> 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
So like, having an architecture marker, that defaults to the current ?
Tarek Ziadé | http://ziade.org
More information about the Python-Dev