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

[Phillip J. Eby]

At 09:43 AM 6/12/2006 -0700, Guido van Rossum wrote:
>On 6/12/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote:
>> >IOW I think PEP 360 is an unfortunate historic accident, and we would
>> >be better off without it. I propose that we don't add to it going
>> >forward, and that we try to get rid of it as we can.
>>
>>4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want
>>to get rid of it, *now* would be the time.
>
>I'm all for it.
>
>While I am an enthusiastic supporter of several of those additions, I
>am *not* in favor of the special status granted to software
>contributed by certain developers, since it is a burden for all other
>developers.

While I won't claim to speak for the other authors, I would guess that they 
have the same reason for wanting that status as I do: to be able to 
maintain an external release for their existing users with older versions 
of Python, until Python-in-the-field catches up with Python-in-development.

Right now, the effective industry-deployed version of Python is 2.3 - maybe 
2.2 if you have a lot infrastructure in Python, and 2.1 if you support Jython.


>I also suspect that the external linking will continue to cause a
>burden for Python developers -- upgrading to a newer version of the
>external package would require making sure that no changes made by
>Python developers in the previous release bundle are lost in the new
>release bundle.

I'd be willing to live with e.g. moving wsgiref to an Externals/wsgiref 
subdirectory of the main Python tree, *without* svn:externals, and simply 
bumping its version number in that directory to issue snapshots.

This would be no different from the current situation (in terms of svn 
usage for core developers), except that I could go to one directory to get 
an "svn log" and review what other people did to the code and docs.  Right 
now, I've got to track at least three different directories to know what 
somebody did to wsgiref in the core.


>I personally think that, going forward, external maintainers should
>not be granted privileges such as are being granted by PEP 360, and an
>inclusion of a package in the Python tree should be considered a
>"fork" for all practical purposes. If an external developer is not
>okay with such an arrangement, they shouldn't contribute.

This is going to make it tougher to get good contributions, where "good" 
means "has existing users and a maintainer committed to supporting them".


>Perhaps issues like these should motivate us to consider a different
>source control tool. There's a new crop of tools out that could solve
>this by having multiple repositories that can be sync'ed with each
>other. This sounds like an important move towards world peace!

First we'd need to make Python's build process support building external 
libraries in the first place.  If we did that, we could solve the problem 
in SVN right now, as long as maintainers were willing to move their 
project's main repository to Python's repository.

If I understand correctly, the main thing it would require is that Python's 
setup.py invoke all the Externals/*/setup.py files.