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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com