Barry A. Warsaw wrote: >>>>>>"MAL" == M <mal@lemburg.com> writes: >>>>> > > >> 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. > > MAL> +1 (maybe with s/site-upgrade/system-packages) > > I like that: system-packages. > > MAL> Not sure whether it's already possible or not, but I'd prefer > MAL> to keep the install command and have the package provide this > MAL> information (site-packages vs. system-packages) as part of > MAL> the setup.py or setup.cfg file. > > Ok, yeah. I think it would be a good idea for the package to somehow > register itself as an upgrade to an existing system package. I still > want the install command to install to site-packages, but whether the > upgrade happens as an upgrade command or "python setup.py install -U" > or some other mechanism is up for grabs. Hmm, maybe I wasn't clear enough: I think that a distutils package should have a flag in its setup.py which lets distutils tell whether it's a site package or a system package, e.g. setup(... pkgtype='site-package' ...) vs. setup(... pkgtype='system-package' ...) (with pkgtype='site-package' as default value if not given) The user would in both cases type 'python setup.py install' but the install command would automatically choose the right target subdir (site-packages/ or system-packages/). -- 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