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

Guido van Rossum guido at python.org
Mon Jun 12 19:42:44 CEST 2006

On 6/12/06, Phillip J. Eby <pje at telecommunity.com> wrote:

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.

Sure, but this doesn't require the draconian "I-and-I-only own the code" approach that you have. There's more code in the source tree that is also distributed externally -- see the table in PEP 291.

>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.

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?)

>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".

To which I say, "fine". From the Python core maintainers' POV, more standard library code is just more of a maintenance burden. Maybe we should get serious about slimming down the core distribution and having a separate group of people maintain sumo bundles containing Python and lots of other stuff. Or maybe we don't even need the latter, if the download technology improves enough (eggs should make it easier for people to download and install extra stuff in a pinch).

>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.

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.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list