[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

[Hanno Schlichting]

Martin Aspeli wrote:
> I just emailed Hanno a few questions, but I thought I'd post them here 
> as well for further discussion:
> 
>   - Is it so that I should check out ploneout, run boostrap.py, then
> ../bin/buildout.sh for each project? Or can I somehow use the same
> checkout of ploneout for multiple projects?

This works against the way buildout works. You could create a seperate
instance (just copy the instance part in the buildout.cfg and rename it
to instance2) and specify a different list of products or eggs that
instance should include.

What we really would want here instead, is being able to reuse the same
Zope checkout or Zope installation in general and potentially also the
bundle checkouts. For the later part this is already possible, as the
instance recipes takes any local folder and symlinks the products found
in there into the instance.

>   - How does that offline I-already-have-a-bundle-checkout-thank-you 
> thing work?

It checks whether or not the offline option is either set for the part
or globally. If one is set and the part directory is in place, the
recipe won't do anything.

>   - I notice that the recipie puts slugs into etc/package-includes; I
> don't think they hurt (once we fix KSS, which ree is doing right
> now!), but they're not really necessary as far as Plone is concerned
> because Products/CMFPlone pulls them in. I'm guessing we should make
> it possible to disable this behaviour?

The slugs are not necessary, I just put them in there to show how the
Zope3instance recipe handles these things and show us an alternative way
of managing those.

>   - I had to easy_install elementtree for openid to be happy; guess we
> should add that as a dependency somewhere?

Yep, as noted in another mail, even Archetypes depends on it.

>   - In my workingenv (i.e. when I've done source bin/activate) I had
> some trouble using 'paster', because it couldn't find various eggs,
> e.g. ZopeSkel, Paste, PasteScript, PasteDeploy and Cheetah. What's
> annoying is that I had to do each one of these manually, i.e. I ran
> 'easy_install ZopeSkel' and it found the egg (without any trip to the
> cheese shop), but then it complained about PasteScript, so I did
> 'easy_install PasteScript', but then it complained about PasteDeploy
> etc. This is while I'm running 'paster create'. Did I do something
> wrong? I think I read somewhere that workingenv can re-use my system
> PYTHONPATH which may or may not be useful

I did not include the global Python site packages, we might want to
change that as Daniel pointed out. I have no idea why easy_install
behaves in those strange ways though.

>   - Once I got it up, I used 'paster create -t plone' to create a new
> project in parts/instance/src/my.package. Is this good practice?

Nope, as Martijn and Daniel already pointed out, don't ever do anything
manually in parts. Everything in there should be managed by recipes and
buildout.cfg. Put those things in the ploneout/src folder instead and
include them from there (probably using buildout's develop option as
said in another mail as well).

>   - I did 'python setup.py develop' in my new package to create a
> development egg. I could then run tests with './bin/zopectl test -m
> my.package --test-path src/my.package'. Is this good practice?

We really need to get the testrunner recipe back into ploneout (I tried
it, but ended up having problems finding the right combination of paths
to be able to run tests). This should give you a test.py in ploneout/bin
which you could use to run all tests and it should include all needed
paths in order for you not having to specify the test path yourself.

Look at
http://dev.plone.org/plone/browser/ploneout/trunk/buildout.cfg?rev=11950
for my last attempt of defining this test script. Something similar
should probably work for all eggs that are managed by buildout. But this
of course doesn't play nicely with workingenv.

>   - Am I supposed to add my own eggs (even if they're not in svn
> anywhere) to the buildout for my project?

If they are not in SVN they should have a release somewhere ;) If you
are in an early stage you could put them into ploneout/src or directly
under ploneout. In the end both the buildout way as well as my
workingenv recipe only need a local path to include them, so you could
manage them outside ploneout completely as well.

>   - How am I meant to update my plone bundles? I tried running
> ../bin/buildout -v again, but that wiped my parts/instance directory!
> It came back, but lacking things like Products/ ...

That's odd. I had no troubles running ./bin/buildout again. This is what
currently should update all Plone specific bundles. Even if the instance
would be recreated it should contain all those products :(

Hanno