>>> Barry Warsaw wrote > This does point out a problem with the batteries-included philosophy > though: it's hard to upgrade packages that come with Python. Say we > release email 3.0 and you want to use it in Python 2.3, what do you do? > You can't just do a distutils install, because site-packages is searched > after the standard library. I think we need more flexibility in > installing distutils packages, so we can install in various locations > that override standard packages (e.g. user-centric, system-centric, > etc.). The approach taken by the XML add-on package doesn't seem to be the right approach, either. At the moment your choices are to manually install the new code over the old, or else have a separate install area that's manually added to the start of the PYTHONPATH (this is what mailman does, right?) Neither of these approaches seem ideal. The latter is what I do for various systems that need newer versions of packages that are bundled with python, it'd be nice if there was a better way - but I can't see one. Anthony
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