-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marius Gedminas wrote:
Disclaimer: my knowledge is not complete, and my track record of writing emails late at night is not very good. Take this with a big grain of salt.
On Fri, Mar 21, 2008 at 11:57:31AM -0700, Timothy Selivanow wrote:
As the subject implies, I'm working on a package for Fedora. I've come across some missing dependencies, and some that are different versions. Because of the way that Python packages are put together (shared library environment), I'm trying to strip out everything that is not Zope specific (e.g. mechanize, docutils, etc.) that way Zope won't clobber already existing packages, and new packages won't clobber Zope.
I would also emphasize (maybe the OP knows this) that it isn't going to be sensible to rely on the Zope3 packages as canonical for packaging "Zope": "Zope3" is not an upgrade / replacement for "Zope2". In particular, Zope2 depends on a specific subset of the Zope3 packages, but also includes a bunch of other packages. The OP might find the following source distributions instructive: - http://dist.repoze.org/zopelib-2.10.5.0.tar.gz contains the Zope2 packages plus the relevant Zope3 code, drawn from Zope 3.3.2. It also includes most of the "foreign" packages the OP identified, except those in the ZODB egg. - http://dist.repoze.org/ZODB3-3.7.2.tar.gz contains the ZODB packages, including transaction and ThreadedAsync. This is the version that the zopelib distribution depends on.
Be careful: I wouldn't be surprised if the foreign packages in the Zope tree have bugfixes applied to them. I trust those fixes were also sent to their respective upstreams as well, but it may make it a bit more difficult to find out which upstream version is really needed.
Here is my list (that I've discovered so far...) and some notes and questions. I would appreciate any information on resolving these. My list was taken from Zope-3.4.0c1/build/lib.linux-x86_64-2.5 (in my arch specific case...) after doing a `python install.py build` (side note, why is it called install.py and not setup.py?).
Good question. It's called setup.py in the Subversion tree -- but the tarball is not based on the old monolithic SVN tree any more.
The Zope3 tarball is already EOLed (there won't be a 3.5 version released as a monolithic tarball, AFAIK). The Zope2 tarball will undergo one final release series (2.11.x), with plans / discussion / work underway to decompose it as eggs for the 2.12 release.
BTrees -- Does not currently exist in Fedora as a separate package. Is this of Zope origin? (If not, where? Required version?) If Zope origin, is it useful outside of Zope?
It is part of ZODB. It may be useful outside of Zope.
persistent -- Does not currently exist in Fedora as a separate package. Is this of Zope origin? (If not, where? Required version?) If Zope origin, is it useful outside of Zope?
ZODB again.
transaction -- Does not currently exist in Fedora as a separate package. Is this of Zope origin? (If not, where? Required version?) If not Zope origin, is it useful outside of Zope?
ZODB again.
Now split out from th ZODB trunk (maybe not released as such yet).
ThreadedAsync -- Does not currently exist in Fedora as a separate package. Is this of Zope origin? (If not, where? Required version?) If Zope origin, is it useful outside of Zope?
ZODB again.
Gone in the ZODB trunk (again, maybe not yet released).
ClientForm -- This currently exists in Fedora (version 0.2.7) Diffing the directories and files reveals differences. What version is required for Zope? What about newer versions?
mechanize -- This currently exists in Fedora (version 0.1.6) Diffing the directories and files reveals differences. What version is required for Zope? What about newer versions?
I'm pretty sure these two are only used for zope.testbrowser. It ought to be sufficient to take the latest upstream version and see if zope.testbrowser's test suite passes with it.
Benji York is the one with most knowledge about zope.testbrowser and its dependencies. If he offers different advice, listen to him, not to me.
twisted -- This currently exists in Fedora (version 2.4.0) Diffing the directories reveals that is it mostly compatible, however, missing some features (I have a list). What parts are required by Zope? Some of the missing parts are no longer being maintained, or are incompatible with newest Twisted (2.5.0). Thoughts?
AFAIK twisted is only bundled with Zope 3 for convenience. It is used for its HTTP server as one of the alternatives (the other ones being ZServer and WSGI), but even that part is not used by default.
pytz -- This currently exists in Fedora (version 2006p) Diffing the directories and files reveals differences. What version is required for Zope? What about newer versions? The Zope versions do not have the .py extension. Possible problems with Zope if they do (i.e., lib resolving)?
I think any non-broken pytz version should work. (Ubuntu once shipped a completely broken one.)
RestrictedPython -- Does not currently exist in Fedora as a separate package. Is this it? <http://pypi.python.org/pypi/RestrictedPython/3.4.2> Required version for Zope? What about newer versions?
I honestly have no idea.
Also, there is an existing package in Fedora called python-zope-interface, version 3.0.1 I assume (in F8), and I'm wondering if it would be worth keeping separate (or at least available, updated, maybe with a Conflicts: zope) in Fedora and are there other parts of Zope (e.g. ZODB, ZEO) that would be useful by themselves?
Yes and no.
The Zope 3 upstream is now split into hundreds of little packages (Python eggs), each registered on the Python Package Index, with intricate and sometimes suboptimal dependency lists. If there's an easy way to convert a Python egg to an RPM, you may want to look at this, but beware: the dust hasn't fully settled yet. There's no guarantee that the packages on PyPI will work with each other at any given point of time. The Zope 3 Known Good Set fixes that, so you may want to look into it: http://wiki.zope.org/zope3/FAQGeneral#what-is-the-kgs-known-good-set
On the other hand having multiple small packages will make your job harder.
I'm sorry if this seems daunting (it is on my side ;) and/or demanding, but I would like this packaged the best possible way for both projects. Who knows, this might show up in future RHEL versions (maybe I'm delusional ;)
The current consensus in the Zope community seems to be "avoid distribution packages, build your own Python from sources, then install Zope from sources in a sandbox". My personal experience with Zope 2 Debian packages reinforces the notion, although I still stubbornly stick with Python that comes with my distro.
The day you spend four hours chasing down bugs caused by a distribution-shipped add-on, either added to or removed from /usr/lib/python2.4/site-packages, will be the day you swear off of it. Maybe if you've started using 'virtualenv --no-site-packages' you can defer that day indefinitely. If I were trying to do the job the OP is tackling, I would put all the Zope packages somewhere like '/usr/share/zope2/lib/python2.4', and arrange for the Zopish scripts to put that directory on the site path, *omitting* /usr/lib/python2.4/site-packages (perhaps via a custom site.py). I don't think I would relish trying to get Zope to work atop a random set of distro-managed packages.
Well, sudo apt-get install zope2.9-sandbox was *very* nice for playing around in a sandbox, but for production use I will install Zope from sources. And I will probably have multiple different installations of different versions of Zope in different sandboxes, because each upgrade has to be carefully tested and scheduled with the clients.
That's the voice of practicality.
The voice of idealism says that yes, every little Zope package ought to be packaged in each popular distro, and these should work together nicely, and be bug-free and fully supported. It will take a lot of time and work to reach that state, and I'm afraid most of the Zopers are too busy building production applications to be much help with this.
Yup, exactly.
At least we have automated test suites...
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5FoJ+gerLs4ltQ4RAlMXAKC9fuQv0/sn/ludEzyi+hVs/FuouACgk1s6 3p5mllkmk3L6OgUXrTNqB2Q= =VBTU -----END PGP SIGNATURE-----