[Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
Phillip J. Eby
pje at telecommunity.com
Mon Jun 12 21:12:20 CEST 2006
At 11:23 AM 6/12/2006 -0700, Guido van Rossum wrote:
>developers contributing code without wanting
>to give up control are the problem.
Control isn't the issue; it's ensuring that fixes don't get lost or
reverted from either the external version or the stdlib version. Control
is merely a means to that end. If we can accomplish that via some other
means (e.g. an Externals/ subtree), I'm all for it. (Actually, perhaps
Packages/ would be a better name, since the point is that they're packages
that are maintained for separate distribution for older Python
versions. They're really *not* "external" any more, they just get
snapshotted for release.)
I guess I should say, control isn't the issue for *me*. I can't speak for
anyone else. Fredrik has raised the issue of API forks, but I haven't
encountered this myself. I *have* seen some developers make spurious
"cleanups" to working code that breaks compatibility with older Python
versions, though, just not in wsgiref.
But I don't mind policing such things myself as long as I have only one
subtree to svn log (versus having to track three separate logs and diffs
for Lib/wsgiref/, Lib/test/test_wsgiref.py, and Doc/lib/libwsgiref.tex, and
then having to reformat the diffs to apply to a different directory layout).
Now, Barry's approach to the email package makes good sense to me, and I'd
use it, except that SVN externals can't sync individual files. I'd have to
create Lib/wsgiref/tests (and make a dummy Lib/test/test_wsgiref that
invokes them) and Lib/wsgiref/doc (and make Doc/lib/lib.tex include
libwsgiref.tex from there). If those changes are acceptable, I'd be happy
to take that as a compromise approach. I'll still have to manually update
the Python PKG-INFO (due to no setup.py), but it'd be better than nothing.
More information about the Python-Dev