Barry A. Warsaw wrote: > But I also think there is a use case for allowing a standard package > to be separately upgraded for a particular Python installation. As > more and more standard Python libraries are packagized, they will > probably have life-cycles separate from the Python core themselves > (this will only be more true once we evolve toward a CPAN-like > arrangement). So I think we will eventually need a way to upgrade > (not override :) a standard library package. +1 > My suggestion would be to prepend a new directory on the standard > search path, let's call it site-upgrade for now. A normal "python > setup.py install" would still install to site-packages, but we'd add a > "python setup.py upgrade" command that would install to site-upgrade. +1 (maybe with s/site-upgrade/system-packages) Not sure whether it's already possible or not, but I'd prefer to keep the install command and have the package provide this information (site-packages vs. system-packages) as part of the setup.py or setup.cfg file. Perhaps we could have some kind of category for distutils packages which marks them as system add-ons vs. site add-ons. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4