Building on Nathan Yergler's work from PyCon, I have just finished a big pile of eggs for both ZopeX3.0.0 and Zope 3.2.0.
Created by tseaver. Last modified 2006-04-05 19:04:42.
Part of the work I did was to reverse-engineer at least a minimal changelog for each of the packages (given the ZopeX3.0.0 version as "first release"). Please have a look:
A couple of notes on the process (summarized from my reply to Martijn Faassen earlier today):
There is some support for "kickstarting" an eggifying project. E.g.:
$ export ZSVN=svn+ssh://svn.zope.org/repos/main $ svn cp -m "Eggify" $ZSVN/productsupport/trunk/project-template \ $ZSVN/zope.foopackage
zope.foopackage will have a skeleton
trunk, plus empty
branches and 'tags':
$ svn co $ZSVN/zope.foopackage/trunk zope.foopackage-trunk $ cd zope.foopackage-trunk $ ls -1 CHANGES.txt develop.py INSTALL.txt README.txt setup.cfg.in setup.py src test.py workspace
The text files are templates, and should be edited to fit.
develop.py script will set up a local
inside your checkout, and try to install dependencies as specified in
setup.cfg (which it copies from
also jams the Zope egg URL into
I usually run
setup.py develop afterwards, as it is better at
finding all the dependencies:
$ PYTHONPATH=lib /path/to/your/python setup.py develop
zope.testing package is supposed to be pulled in during that
bootstrapping, but often seems missed (I haven't yet figured out
why). Running the local
easy_install does the trick:
$ PYTHONPATH=lib /path/to/your/python bin/easy_install \ zope.testing
src/zope directory is intended to contain a
pointer to the "canonical" location of the source (we may eventually
reverse this, and make the main Zope tree point out at the top-level
package directories). E.g.:
$ svn propedit svn:externals src/zope #... add your external here $ svn up # ... fetches your external.
src/zope directory also contains "setuptools / pkgutil"
boilerplat namespace __init__.py:
$ cat src/zope/__init__.py # namespace package boilerplate try: __import__('pkg_resources').declare_namespace(__name__) except ImportError, e: from pkgutil import extend_path __path__ = extend_path(__path__, __name__)
test.py needs to be edited to point to your package. At that
point, you should have all your package's dependencies installed
(assuming that you named them in
setup.py), and should be able to run
the tests using your local eggs:
$ PYTHONPATH=lib /path/to/your/python test.py
Observations I jotted down while running through this process a dozen or so times:
zpkgbased solution was weird, but the egg-based one isn't much better.
I was trying to handle those cases without actually installing the
dependencies anywhere but the local sandbox, which led me to create
include directory inside the packaging directory, and add the
package with the header as an
svn:externals entry there.
svn:externalsto ensure that I was pulling in the correct versions for 3.0.0 and 3.2.0. Please let me know if I fat-fingered any of them (I wish viewcvs would expose the externals!).
Give a dependency-driven install of a pile of packages a spin. E.g.:
$ mkdir aside $ PYTHONPATH=aside \ /path/to/setuptools/enabled/python /path/to/easy_install \ --install-dir=aside \ --find-links=http://download.zope.org/distribution/ \ zope.documenttemplate[untrusted]
That command kicks off an interesting process:
zope.documenttemplatepackage (the 3.2.0 version, given the URL we passed), and tries to install it, using the added
zope.securityand its dependencies, based on the feature.
asidedirectory, along with the
setuptoolsbookkeeping stuff needed to stitch them all together.
zope.appin 3.0.0 / 3.2.0 (avoidg
zope.appbecause detangling the dependencies inside that beast is too painful to think about):
docutils(we should be able to use a stock one from the Cheese Shop, I think)
zope.app, prefereably using some kind of automated tool (maybe the
zpkgeggstuff which Nathan prototyped?)