[Python-Dev] "setuptools has divided the Python community"

Jean-Paul Calderone exarkun at divmod.com
Wed Mar 25 17:37:39 CET 2009


On Wed, 25 Mar 2009 11:34:43 -0400, Tres Seaver <tseaver at palladion.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Antoine Pitrou wrote:
>> Tarek Ziadé <ziade.tarek <at> gmail.com> writes:
>>> But I agree that the sizes of the packages are too small now, and it has gone
>>> to far. Installing a web app like Plone is scary (+100 packages)
>>
>> I am working on a TurboGears2-based app and I just did a count of the .egg
>> packages in the virtualenv. There are 45 of them....
>>
>> People should really stop splitting their work into micro-libraries (with such
>> ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of
>> separately-packaged plugins (the repoze stuff). The Twisted approach is much
>> saner, where you have a cohesive whole in a single package.
>
>Monoliths have downsides:  consider that fact that the WSGI-complieant
>HTTP server for Twisted languished for *years* outside the released
>versions of Twisted:  IIRC, the server was released as a separate
>distribution, but it was not compatible with the released versions of
>the main Twisted distribution:  you had to install a snapshot / alpha of
>Twisted to get the 'web2' server to work.

Maybe monoliths have downsides, but please pick a different example to
support this.  The manner in which the WSGI server in Twisted Web2 was
made available has very little to do with large vs small packages and
much to do with our (the Twisted developers) decision /not/ to release
Twisted Web2 at all.  I could go into lots more detail about that
decision, but I don't think any of i  would be relevant to the topic at
hand.

If anything, Twisted's example shows how monolithic packages are easier
all-around than micro-packages.  We basically have the release infrastructure
to release Twisted in many smaller pieces, and we even do - but we only
make releases of all the smaller pieces simultaneously, we encourage people
to use the "Twisted" package which includes all the pieces, and we don't
do any testing of mixed versions of the smaller pieces because it would be
very difficult.

Further, we *have* done point releases of /all/ of Twisted to supply some
critical bug fix (these generally take the form of a X.Y.1 release, we
rarely go to .2 or higher these days).  And we've done these quite rapidly
when the need arises - the monolithic nature of Twisted isn't really a
hindrance here (updating our website, a manual process, is far more time
consuming than actually doing the release - and a big part of that cost
comes from the fact that we have web pages for each smaller piece, even
though we don't encourage people to use these!).

So, as long as we're just talking about the vagueries of "monolithic" vs
"micro", I'll weigh in in favr of monolithic (but I'm open to discussion
about specific issues which are much more interesting than abstractions).

Jean-Paul


More information about the Python-Dev mailing list