Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
Hey, I only caught this message earlier today, but this is really cool! It's really nice to see some zope 2 recipes and I hope they indeed will end up on svn.zope.org soon! Your workingenv recipe sounds very interesting and I should try this soon. Does it allow easy_install to be used as well? If so, what does that mean (do paths get updated?) I'll be playing with these recipes first excuse I get. :) Regards, Martijn
Hi, Martijn Faassen wrote:
Hey,
I only caught this message earlier today, but this is really cool! It's really nice to see some zope 2 recipes and I hope they indeed will end up on svn.zope.org soon!
I have sent my contributer agreement per snail-mail last week to Zope Corp. so it might turn up on somebody's desk in the next days. Then I'll move those recipes...
Your workingenv recipe sounds very interesting and I should try this soon. Does it allow easy_install to be used as well? If so, what does that mean (do paths get updated?)
All it does is to call workingenv itself on the created Zope instance (any folder really). You get the usual activate script you need to run to enable the workingenv and let easy_install install into the workingenv. If this should turn out to be a good way we would want to activate the workingenv in some scripts automatically, like zopectl for instance. In addition to supporting workingenv's requirements option (a file with a list of dependencies) I also implemented a simple option to let it call setup.py develop on a number of specified packages, so these get installed into the workingenv as well. Note however that I did not understand how to effectively use buildout's system of eggs and develop-eggs, so this might be a duplicated effort. My use case here was to get 19 Python packages from SVN (which aren't released in any way) and use those as a SVN checkout, but include them into the Zope instance in development mode, so I can still work with my SVN checkout as I do now, but have those packages available in the instance with all their egg information like entrypoints.
I'll be playing with these recipes first excuse I get. :)
That would be great. Those recipes need a definitive review by someone who knows more about buildout. I felt like I was fighting against buildout in some places. All I wanted to get is a running Plone development environment which includes real eggs in development mode, rather then just dumping in the packages without any egg information like we currently do. These recipes are currently more of a (working) prototype right now, to let us explore buildouts capabilities in a real complex situation and to get some interested (Plone) folks to try it and provide feedback. Hanno
Martijn Faassen wrote:
Hey,
I only caught this message earlier today, but this is really cool! It's really nice to see some zope 2 recipes and I hope they indeed will end up on svn.zope.org soon!
Your workingenv recipe sounds very interesting and I should try this soon. Does it allow easy_install to be used as well? If so, what does that mean (do paths get updated?)
I believe so.
I'll be playing with these recipes first excuse I get. :)
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? - How does that offline I-already-have-a-bundle-checkout-thank-you thing work? - 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? - I had to easy_install elementtree for openid to be happy; guess we should add that as a dependency somewhere? - 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 - 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? - 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? - Am I supposed to add my own eggs (even if they're not in svn anywhere) to the buildout for my project? - 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/ ... Martin
I only know the answer for a few of these... Martin Aspeli wrote:
- 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
workingenv has the --site-packages option which includes all site packages available at install time. I'm not sure what's going on in your case though, because those dependencies should certainly be tracked down normally, no?
- 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?
I believe you're not supposed to put anything into parts/. parts/ is buildout's playground.
- 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/ ...
Welcome to the wonderful world of buildout. *scnr* ;-) Daniel
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
Martijn Faassen wrote:
Hey,
I only caught this message earlier today, but this is really cool! It's really nice to see some zope 2 recipes and I hope they indeed will end up on svn.zope.org soon!
Your workingenv recipe sounds very interesting and I should try this soon. Does it allow easy_install to be used as well? If so, what does that mean (do paths get updated?)
I believe so.
I'll be playing with these recipes first excuse I get. :)
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? - How does that offline I-already-have-a-bundle-checkout-thank-you thing work? - 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? - I had to easy_install elementtree for openid to be happy; guess we should add that as a dependency somewhere? - 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 - 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? - 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? - Am I supposed to add my own eggs (even if they're not in svn anywhere) to the buildout for my project? - 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/ ... Martin
participants (4)
-
Daniel Nouri -
Hanno Schlichting -
Martijn Faassen -
Martin Aspeli