[Python-Dev] Please stop changing wsgiref on the trunk

[Guido van Rossum]

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.

> There is an approach that would address this issue and others relating to
> external packages, but it would require changes to how Python is
> built.  That is, I would propose a directory to contain
> externally-maintained packages, each with their own setup.py.  These
> packages could be built and installed with Python, but would then also be
> separately-distributable.
>
> Alternately, such packages could be done using svn:externals tied to
> specific release versions of the external packages.
>
> This idea would address the needs of external maintainers (having a single
> release history) while still allowing Python developers to modify the code
> (if the external package is in Python's SVN repository).

Even that is a burden on regular Python developers. For example, when
I do "svn up" in the PEPS directory, which has such an arrangement for
the docutils, it usually spends (much) more time deciding that there's
nothing new in the docutils than it spends on the rest of the update.
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 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.

Note: I'm saying "going forward". I'm not saying that this "tough
luck" policy should be applied to the packages that have already been
accepted; I don't want the PSF to break its work. Although I'd
encourage their authors to loosen up.

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!

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