RE: [Python-Dev] PEP 250 - site-packages on Windows: (Was: [Distu tils] Package DB: strawman PEP)
From: M.-A. Lemburg [mailto:mal@lemburg.com]
They should be in the CVS tree of Python on SourceForge. I don't have CVS access, so I can't get at these, unfortunately...
About the change: I think distutils should lookup the path in Python's site.py file - that way you assure that distutils will work on all Python installations rather than only on those which have the site.py patch. Otherwise, Python won't find the packages installed in Lib/site-packages.
I'm not sure what you intend, here. site.py doesn't export this directory - it is just one of the directories which gets added to sys.path in site.py. On Unix, there are more than one such directory (both version-specific and version-independent), so there isn't, in general, just one such directory. I don't know how you could encapsulate this in a way which would not clash with other platforms' policies. The intention of this change was to be the smallest possible change which would work. I believe it (or at least, the patch I sent when I submitted the final version of the PEP) does that for everything except the Windows Installer. I'll have to defer judgement on how best to address that area to others better qualified to comment, but see my message to Thomas for my suggestion. Hope this helps, Paul.
"Moore, Paul" wrote:
From: M.-A. Lemburg [mailto:mal@lemburg.com]
They should be in the CVS tree of Python on SourceForge. I don't have CVS access, so I can't get at these, unfortunately...
There should be a tarball of the CVS archive available somewhere on SF.
About the change: I think distutils should lookup the path in Python's site.py file - that way you assure that distutils will work on all Python installations rather than only on those which have the site.py patch. Otherwise, Python won't find the packages installed in Lib/site-packages.
I'm not sure what you intend, here. site.py doesn't export this directory - it is just one of the directories which gets added to sys.path in site.py. On Unix, there are more than one such directory (both version-specific and version-independent), so there isn't, in general, just one such directory. I don't know how you could encapsulate this in a way which would not clash with other platforms' policies.
The intention of this change was to be the smallest possible change which would work. I believe it (or at least, the patch I sent when I submitted the final version of the PEP) does that for everything except the Windows Installer. I'll have to defer judgement on how best to address that area to others better qualified to comment, but see my message to Thomas for my suggestion.
Well, site.py could be modified to set a symbol in the sys module which could then be queried by distutils, e.g. sys.extinstallprefix. Alternatively, distutils could be made to default to Lib\site-packages and then revert to Lib\ in case this directory is not available. BTW, I don't think that using Windows registry keys for determining the installation path is a good idea -- this information should be kept in the site.py or sitecustomize.py module for easy editing. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
[I've cut down the To: and CC: headers to olny include python-dev and distutils]
Well, site.py could be modified to set a symbol in the sys module which could then be queried by distutils, e.g. sys.extinstallprefix.
Alternatively, distutils could be made to default to Lib\site-packages and then revert to Lib\ in case this directory is not available.
BTW, I don't think that using Windows registry keys for determining the installation path is a good idea -- this information should be kept in the site.py or sitecustomize.py module for easy editing.
The problem is that the 'installation path' information must be loaded at run time by the windows installer, and it may not always sucessful to embed python at run time and let python code retrieve it. Remember the problems we had with Python2.0 on win95/98, when win32all was not installed? The installer was not able to compile the installed files to pyc/pyo because of this path bug. Anyway, how does bdist-rpm does it? Should be the same problem there... Thomas
Thomas Heller wrote:
[I've cut down the To: and CC: headers to olny include python-dev and distutils]
Well, site.py could be modified to set a symbol in the sys module which could then be queried by distutils, e.g. sys.extinstallprefix.
Alternatively, distutils could be made to default to Lib\site-packages and then revert to Lib\ in case this directory is not available.
BTW, I don't think that using Windows registry keys for determining the installation path is a good idea -- this information should be kept in the site.py or sitecustomize.py module for easy editing.
The problem is that the 'installation path' information must be loaded at run time by the windows installer, and it may not always sucessful to embed python at run time and let python code retrieve it. Remember the problems we had with Python2.0 on win95/98, when win32all was not installed? The installer was not able to compile the installed files to pyc/pyo because of this path bug.
Ok. Point taken (this time ;-).
Anyway, how does bdist-rpm does it? Should be the same problem there...
bdist_rpm runs the Python interpreter to figure out the install dirs, etc. at rpm build time. The paths are then hard-coded into the rpm file. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
participants (3)
-
M.-A. Lemburg -
Moore, Paul -
Thomas Heller