[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 19:08:52 CEST 2006

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.

More information about the Python-Dev mailing list