[Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk) (original) (raw)

Phillip J. Eby pje at telecommunity.com
Mon Jun 12 20:32:05 CEST 2006

At 10:42 AM 6/12/2006 -0700, Guido van Rossum wrote:

Sure, but this doesn't require the draconian "I-and-I-only own the code" approach that you have.

If there were only one version and directory tree to maintain to do both the Python trunk and the external version, I wouldn't mind other people making changes. It's the synchronization that's a PITA, especially because of the directory layout.

If we had Externals/ I would just issue snapshots from there.

And is that such a big deal? Now that wsgiref is being distributed with Python 2.5, it shouldn't evlove at a much faster pace than Python 2.5, otherwise it would defeat the purpose of having it in 2.5. (And isn't it just a reference implementation? Why would it evolve at all?)

This is backwards: I'm not the one who evolved it, other Python devs did! :) I want Python 2.5 to distribute some version of wsgiref that is precisely the same as some public wsgiref release, so that PEP 360 will have accurate info and so that people who want a particular wsigref release can specify a sane version number, to avoid the kind of skew we used to have with micro-releases (e.g. 2.2.2).

If I understand correctly, the main thing it would require is that Python's setup.py invoke all the Externals/*/setup.py files. I guess that's one way of doing it. But perhaps Python's setup.py should not bother at all, and this is up to the users.

However, if Python's setup.py did this, then external developers would get the benefit (and discipline) of the buildbots and testing. That seems like a good thing to me.

More information about the Python-Dev mailing list