> ugh... could we devote a little time to packaging love here? maybe at
> the conference? This is tipping my suckometer.
> None of this is too fancy, but I think we've exceeded the utility of our
> bundle system and should fix our dev deploy story.
> some notes in this arena::
> * I just fixed the bug in all versions of zope that make you have to
> manually edit zopectl and runzope to use workingenv with zope.
> * workingenv can take recipes of stuff to install in your environment
As far as I know, these recipes are simply Requirements in the
setuptools sense. This is an example of a requirement (=recipe?):
> * workingenv can checkout eggs in -e mode so you can have svn copies to
> work on.
Does workingenv checkout using -e *and* run python setup.py develop?
If so, I think I'd still usually prefer having one checkout of a
library regardless of how many other projects (or instances) use them.
> * this mean all plone python deps need to be reasonable eggified;
> luckily this can be as easy as getting a properly formated link on a
> download page pointed at svn. we could create omnibus packages
> though(makes working on stuff much easier).
I think there should be one Plone egg, namely "plone.app", that
depends on both all Python libraries (aka lib/python) and all Products
that Plone requires. As far as the Zope 2 Products are concerned, I
believe that one egg to include them all should be enough. I blogged
about making an egg out of all Plone Products .
Note that with workingenv, the installation procedure becomes a snap.
One "plone.app" package depends on everything needed, and thus a
"easy_install Plone" is enough to download all dependencies.
> * we would need to register our packages with PyPi
Which is really easy, because all the infrastructure is in place, see
 for example.
> * we would need to set up a page on plone.org with links that tell
> setuptools where to get the right packages.
> * we need to fix the retarded behavior of the zope testrunner that makes
> you explicitly state the test-path in order to run an egg's tests.
See the reply to your other mail.
> * for Products, we could do a few different things:
> - use a custom zope skeleton(mkzopeinstance takes skel arg) that has
> a dev bundle for a Products dir.
> - use a symlink script like Rob's
> (does instancemanager do this too?)
> * we need something to tie it all together(aka the download and execute
> this script):
> - create a buildout that creates a workingenv via our recipe, checks
> out the bundle, an makes zope with said bundle
I'm not sure if buildout is really necessary here. I think we should
try and start simple, with a script that runs workingenv.py, creating
a working environment and Zope therein. The same script could then
"easy_install Plone" in that workingenv and help the Plone packages in
lib/python put their zcml into the etc/package-includes directory.
I realize the last part with the zcml is ugly... and it is still ugly
when you use buildout. However, this script should be easily
converted to a buildout recipe, if need be.
Framework-Team mailing list