On Sat, 2008-03-22 at 08:05 +0100, Andreas Jung wrote:
In general we want to get rid of 3rd-party packages we don't want to maintain on our own.
That's perfectly sane :) There is no sustainable reason to lug around some other project's code in yours in the Open Source world.
Right now we have several 3rd-party packages like Docutils in our svn for several reasons. Some of those packages are basically frozen (because we made local changes e.g. for security reasons). So if you rip out those packages you have to guarantee that they will _never_ be updated by a new official package (because local changes might get lost). On the other hand you must ensure that changes to our local 3rd-party packages will be available through your packaging mechanism. As said: this is a challenging task for us right now - it will be even more challenging and more error-prone for outsiders.
Now when I say "rip out", I don't mean repackage (make a sub RPM), I mean remove from the RPM that I am making. I don't want to provide a "new" Docutils. I'm actually trying to place zope in the standard (for Redhat) python site-packages location while guaranteeing that the zope RPM doesn't provide more than it needs, and doesn't clobber other packages, like the native Docutils. If I knew what versions the 3rd party pieces were, I could make a diff (or the Zope project could provide one) and I could get those into the official Fedora RPMs (esp. if they are security fixes). Fedora doesn't like keeping those patches forever, so I would also get those pushed upstream.
The trend in all Zope-related projects (Zope 2,3, Grok, Plone) is definitely: self-contained installation. Why self-contained? Different projects require different modules in different versions.
That is completely understandable from a Service Provider standpoint, but not a distro. However, coming from a Service Provider background (my day job, as it were), I definitely like reproducibility, and a distro package (i.e. RPM) is a good place to start. It's very annoying and time consuming to replicate by hand the environment that is going to appear on several servers, esp. over long periods of time (not to mention upgrades/security, etc...)
Messing a Python installation with e.g. ZODB from different versions will end up in an disaster. So the message of the Zope community is in general: keep your Python installation clean and use zc.buildout or virtualenv for installing your other modules within an isolated environment. This is meanwhile considered best-practice. Using Python eggs and easy_install you have _the official_ tools in your hand for installing 3rd-party packages..that's the Pythonic way to do it, not using some distro packaging tool.
One could argue that the distro over-rides all. In a distro role, your job is to provide the least common denominator, not cater to every crazy developer and their environment. They should be more than capable of maintaining that themselves (install several different versions of python, zope, et al. in their home dir if need be).
This was never my point. For me it would make more sense that the packages would take the official release and re-package it as a whole without splitting it up. Dependency management should happen on our side as a whole, not on the distribution site.
Yes, but I still have to meet those dependencies. I was just hoping that there would be pieces (sounds like ZODB and zope.publisher would be good candidates from some of the other threads) that would be useful outside of the whole Zope Application Server scope. I assumed that as a (open source) software project, Zope would be delighted that people were using their code in new and creative ways. I wanted to help facilitate that by offering those pieces as a stand-alone library.
I don't know how important Zope distro packages are for users. My personal impression is: not so important.
Developers, yes, not very important. /Users/ on the other hand are a completely different animal, and packages are _very_ important. I suppose it's a matter of semantics on what exactly a user is in which scope.
Zope packages at this point might be good for getting into touch with Zope but for deployment packages are basically no used - but correct me if I should be wrong. Since a while we have tools in place to bootstrap Zope 2/3 projects, Plone installations and Grok installations very easily and in a reliable way.
It matters in an unattended, (e.g.) 100+ server enviro where reproducibility is a must.
I know that those approaches don't comply directly with your package mechanisms but I would expect that the "offical" installation and deployment stories by the Zope community should be taken into account (in some way).
Absolutely. Those are important. I would be delighted to read some of those if someone knew/had some.
One last thought: you might check out the packaging efforts by the Plone project. They provide possibly also packages for Fedora on their own (which includes Zope 2 afaik (the "universal installer")). It might make sense to share experiences with them and leverage from their experiences.
Sounds like they will be the next list I hit up (sigh...my number of subscribed lists is exponentially increasing ;) I've been kinda following the egg-ification and zope.producer dependency reduction threads, and it seems like all of that would be good for me too (any packager really...)
But don't get me wrong. I have nothing against distro-specific packages but they should be done in the right way. "Right" means for the user: they are consistent with the official documentation and best-practices as used within the offical Zope world - "Right" for the supporters within the Zope world: we don't have to deal with issues caused distro-specific packages (e.g. configurations are different from the standard, paths are different from the standard etc.).
Which is why I'm here asking for input. Perhaps I didn't start out correctly from a Zope'ish POV, but I needed to know where the conflicts were going to show up. If I packaged Zope as-is, placing it in (what I would think as) the standard python site-packages, it would never pass scrutiny because of the extra stuff it has, and would never be included in the distro. In older packages that /were/ in Fedora (they are no longer...), Zope was placed in a completely isolated environment, making it *only* useful as an web application server. I would rather have a package that upstream approves of and participates in, than blindly create it in a silo not caring. It never turns out well in the long run with the latter. --Tim __________________________________________________________________ / I saw a subliminal advertising executive, but only for a second. \ \ -- Steven Wright / ------------------------------------------------------------------ \ \ \ \ /\ ( ) .( o ).