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

[Guido van Rossum]

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