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

Giovanni Bajo rasky at develer.com
Mon Jun 12 20:20:10 CEST 2006

Guido van Rossum wrote:

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.

-1000.

One of the biggest Python strength, and one that I personally rely on a lot, is the large standard library. It means that you can write scripts and programs that will run on any Python installation out there, no matter how many eggs were downloaded before, no matter whether the Internet connection is available or not, no matter if the user has privileges to install extensions, even if the SourceForge mirror is down, even if SourceForge changed their HTML and now the magic code can't grok it anymore, etc etc etc.

If Python were to lose this standard library in favor of several different distributions, users could not sensibly write a program anymore without incurring the risk of using packages not available to some users. Perl has this problem with CPAN, and system administrators going through hoops to write admin scripts which do not rely on any external package just because you can't be sure if a package is installed or not; this leads to code duplication (duplication of the code included in an external package, but which can't be "reliably" used), and to bugs (since the local copy of the functionality can surely be more buggy than the widespread implementation of the external package).

Let's not get into this mess, please. I think we just need a smoother way to maintain the standard library, not an agreement to remove it, just because we cannot find a way to maintain it properly. The fact that there hundreds of unreviewed patches to the standard library made by wannabe contributors is a blatant sign that something can be improved.

Giovanni Bajo

More information about the Python-Dev mailing list