Re: [Framework-Team] Re: Error starting 3.0 bundle
Daniel Nouri wrote: 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?): https://svn.openplans.org/svn/training/pylons/requirements.txt iirc, recipes for workingenv also take a '-r somefile-or-url' argument that allows for chaining of recipes. * 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. not totally sure. have not had a chance to set this up for tagger. * 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. indeed. * we would need to set up a page on plone.org with links that tell setuptools where to get the right packages. +1 * 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. agreed. -w begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield email;internet:[EMAIL PROTECTED] tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Error starting 3.0 bundle
Daniel Nouri wrote: whit wrote: You could call it temporary in that Zope will hopefully get better at development eggs and therefore render a weaved-together bundle like this obsolete (instead, you'd have a bundle with eggs and then you'd easy_install each one). To be honest, I find the bundle fairly convenient though, just co and ln into lib/python. currently, the only thing that zope does wrong with eggs is zope.testing. if you use --test-path=/path/to/dev/egg, the test-runner will even work with eggs(though this is super annoying). Now that the PYTHONPATH bug is fixed, you could conceivably just put the plone-lib dir on the PYTHONPATH and zope could find it. Personally, I see this as a stop gap to doing the due diligence to get our own egg story sanified(and we should fix zope.testing on the way). so really, this is our problem now, not zope's. This is biting the Zope 3 people *right now*, too. I wonder what Philipp wrote in his the new edition of his book about eggs and tests. I have been bitten by zope.testing too... :-/ I took a look at the zc.testrunner.recipe; it allows for the configuration of extra test paths (good if you know exactly what packages you will be working on). The sensible behavior of nose is still missing; it seems explicit enough if I say test -s some.package I mean the tests that live in that package on my PYTHONPATH. The current arrangement(in zope2) only searches lib/python and Products by default. also, zope2 itself is just a few minor changes away from being egg installable itself at which point we should be able to deal with everything outside of Products via egg recipes. my opinion is a little elbow grease to get this worked out now rather than later would go a long way. eggs are bit of pain, but we don't need to wait for any zope gods to descend from on high to make things better. I mean... if you could say easy_install Plone3=dev and be ready to work, how cool would that be? Kevin Dangmoor attribute much of TG's success and rapid growth to making the packaging work. rant off/ +1 I really hope I can put some time into this in the following days. awesome! this makes me feel better. I truly do feel we aren't that far away from having a much happier packaging and dev situation than we have now. -w begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield email;internet:[EMAIL PROTECTED] tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Error starting 3.0 bundle
whit wrote: You could call it temporary in that Zope will hopefully get better at development eggs and therefore render a weaved-together bundle like this obsolete (instead, you'd have a bundle with eggs and then you'd easy_install each one). To be honest, I find the bundle fairly convenient though, just co and ln into lib/python. currently, the only thing that zope does wrong with eggs is zope.testing. if you use --test-path=/path/to/dev/egg, the test-runner will even work with eggs(though this is super annoying). Now that the PYTHONPATH bug is fixed, you could conceivably just put the plone-lib dir on the PYTHONPATH and zope could find it. Personally, I see this as a stop gap to doing the due diligence to get our own egg story sanified(and we should fix zope.testing on the way). so really, this is our problem now, not zope's. This is biting the Zope 3 people *right now*, too. I wonder what Philipp wrote in his the new edition of his book about eggs and tests. I have been bitten by zope.testing too... :-/ also, zope2 itself is just a few minor changes away from being egg installable itself at which point we should be able to deal with everything outside of Products via egg recipes. my opinion is a little elbow grease to get this worked out now rather than later would go a long way. eggs are bit of pain, but we don't need to wait for any zope gods to descend from on high to make things better. I mean... if you could say easy_install Plone3=dev and be ready to work, how cool would that be? Kevin Dangmoor attribute much of TG's success and rapid growth to making the packaging work. rant off/ +1 I really hope I can put some time into this in the following days. Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Error starting 3.0 bundle
whit wrote: - use a symlink script like Rob's https://svn.openplans.org/svn/bundles/openplans-zope29-bundle/deploy.sh (does instancemanager do this too?) instancemanager only handles the normal Products/* stuff at the moment. It is actually a good idea to handle the python libs and Extension stuff, too. I'll probably need to do some addition thinkwork to weed down the amount of options in instancemanager, first, before adding new ones :-) Reinout -- Reinout van Rees r.van.rees @ zestsoftware.nl http://vanrees.org/weblog/ http://zestsoftware.nl/ Military engineers build missiles. Civil engineers build targets. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Error starting 3.0 bundle
whit wrote: my opinion is a little elbow grease to get this worked out now rather than later would go a long way. eggs are bit of pain, but we don't need to wait for any zope gods to descend from on high to make things better. I agree in principle, I just can't bring myself to spend lots of time on low-level setup when I really just want to get something done. I still haven't managed to get eggs to work reliably for tests or Zope startup. I also find it a bit difficult to work with workingenv.py - not terrible, but I tend to interact with the same Zope instance in more than one terminal and then I need to keep the active env's in sync. And heaven knows how any of this works on Windows... I would love to see a clear and well-documented (!) story for this! Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
