[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 mailing list