Delaney, Timothy wrote: >>From: martin@v.loewis.de [mailto:martin@v.loewis.de] >> >>"M.-A. Lemburg" <mal@lemburg.com> writes: >> >> >>>Perhaps we could have some kind of category for distutils >>>packages which marks them as system add-ons vs. site add-ons. >> >>One approach would be for distutils to have a list of system packages >>built-in, depending on the Python release. > > > +1 > > Arbitrary package authors shouldn't be able to state that their package is a > system package - that should be up to the core team. Hmm, I don't really see the need to make this more complicated. Package authors should be sensible enough to not create system packages unless these are actually part of the core or understood as optional but standard add-on (e.g. the Japanese codecs could be such an add-on). Besides, it's easy enough to achieve the same effect by subclassing the install command in your setup.py, so there is not much gained security there. The only advantage I see in Martin's approach is that it would seem backwards compatible, but then: installing a system package in a pre-2.3 system would not have the desired effect at all, so the gained backwards compatibility can't really be put to use. -- 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