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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4