I feel a bit like an journalist digging up stuff from the trenches and presenting it to a wider audience for evaluation (i.e. posting about portal_view_customizations) but there has been another topic lingering in the background and coming up now and again on several mailing lists. There is a sentiment (and lament) to it, similar to the TTW issue.

I noticed it first, when I released the first beta version of Quills 1.6") ca. one month ago. Being a "Plone 3.0 only" release, I had worked on it using a custom buildout configuration which was just fine and dandy... for me.

When releasing the beta I initially hadn't even included a tarball, instead (thinking I was making it easier for potential beta testers) I simply referred to aforementioned buildout and included even a handy one-liner that would get you going.

The sentiment I was following (unconsciously at the time) seems to be prevalent among other developers, namely that buildout is easy to use, even for end users. "I mean, c'mon, it's only one line of copy-and-paste... how hard can it be?!"

Well, that's certainly true, if viewed in isolation. But the truth is, as usual, far more complex. I received several questions (and even complaints) both on and off-list afterwards. Just as with the TTW story, there was this notion of "This used to be easier! Why are you developers forcing this complicated new stuff upon us? Sure, it may be easier for you, but what about us?" (I'm grossly paraphrasing here, mainly because I think these complaints are indeed very valid.) The issues that came up fell mainly into two categories: either buildout itself gave rise to trouble (Windows related or python related) or people wanted to test Quills in their existing setup and were left puzzled as how to achieve that.

Well, one reason is, that things have indeed become more complicated with Zope 3. Let's not mince words here:

What (error prone, hard-to-debug, rot-in-hell-evil) magic Zope 3 takes away from Zope 2 it has to make up with additional paperwork.

Namespace-packages, .zcml, .cfg, the whole "multicomponadapterfaces" shebang. While most of this is only of concern to developers (who mostly are eager to make that trade-off - believe me, once you got used to the 'new style' you don't ever want to go back) some of this (currently) also has repercussions for end-users and integrators. Packaging (finally coming back to the title of this post) being one of them.

Let's (continue to) take Quills as an example. This used to be just a bunch of ordinary 'capital-"P"-Products' that you downloaded as a bundle and popped into your Products folder - presto! Now it's made up of several components (5 products and 4 packages). From a developers point of view that is a good thing, as each component does less and is easier to debug and maintain. For an integrator its (again) just extra sit-ups: "What needs to be copied where? Do I need to copy the whole quills.core directory or just quills.core/quills/core?" etc. pp.

Personally, I've always found the "unpack it and stick it into Products" approach rather inelegant but most people have accepted this as the de facto method of distribution and installation of Plone add-ons. This tolerance might start to wear thin, though, now that it's basically coming to "unpack it and stick certain bits into Products and others into lib/python/ (wherever that is on your system, good luck with finding it...) and stick something called zcml-slugs into etc/site-packages".

Like with the TTW issue I'm just playing the messenger here, though. I just want to work on Plone features and cool Plone products that users out there (hopefully) will find useful... if they can be bothered to get them installed, that is...

It's not as if the designers of Zope 3's component architecture hadn't come up with a design solution to this mess, though. Their answer is: use eggs. That way end users and integrators just need to download a few zip files (and stick them into some 'magic' folders... sound familiar?).

The problem is, Plone won't be entirely eggified for quite some time, as I understand it. 'Old-Style' Products can't be eggified, either and not all Products can simply be converted into packages, etc. etc.

As I mentioned, tolerance is starting to wear thin, adoption of Plone 3 is being slowed down. Somebody needs to make sure that the new Zope 3 way of doing things is followed all the way through to the end user. Currently it's stuck somewhere at the developer's feet. This needs to change.

So, I'm afraid this might turn into some sort of 'signature ending' of mine, but I'm ending this post, too with... "Any takers?" ;-)