[Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)
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