whit wrote:
> 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 [1].

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
[2] 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 
> https://svn.openplans.org/svn/bundles/openplans-zope29-bundle/deploy.sh
>      (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.


[1] http://danielnouri.org/blog/devel/zope/plone-in-an-egg.html
[2] http://hannosch.blogspot.com/2006/09/having-fun-with-setuptools.html

Framework-Team mailing list

Reply via email to