[Zope-dev] Re: Packaging Zope for Fedora

Tres Seaver tseaver at palladion.com
Fri Mar 21 20:59:53 EDT 2008 

-----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 at 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-----

More information about the Zope-Dev mailing list