[Barry] > >I wonder if decoupling more of the standard library isn't a good idea, > >although it flies in the face of "batteries included". One thing I [AMK] > I'd like this approach, though perhaps the "Batteries Included" > distribution rather than the standard library should be handled like > this. For a batteries included release, this would be great. > It would also require finalizing a catalog implementation (at > last!) I believe Kapil is working on it; he's presenting a paper at OSCON2002. > An open question is how to avoid the CPAN trap of having your modules > require you to upgrade your Python installation. Perhaps each module > version would specify the Python version it's compatible with. > > Module version compat. with > 0.0.1 Py2.1 > 0.0.2 Py2.1 > 0.0.5 Py2.2 Ideally it should list a range of versions (or a set?). Of course, the upper end of the range may need to be adjusted when new releases come out -- nobody knows whether Module 0.0.5 will be compatible with Py2.3 until the latter is released. > So when you're on Python 2.1, you can only get upgraded to 0.0.2. The > problem is, if the developer of version 0.0.5 didn't realize that it > was incompatible with 2.1, you'll get upgraded to it and your system > will be broken. > > (Take package management far enough and you begin to reinvent Debian's > APT. I wonder if we could write a dpkg-like tool in Python and then > just use APT on top of that?) I think version dependency management is subject to the Logajan paradox. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)
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