Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
Daniel Nouri wrote: [...]
- There is a single file that shows me what eggs and development eggs make up my package. This makes it easy to add new eggs, for example - and also easy to remove them again. With workingenv-based solutions, you can specify a file full of eggs to install when it's first set up, but from that point onwards, the environment can grow as you easy_install new things. It's not immediately clear to me how you reconcile all the eggs you've installed (not all of which may be needed when you're done trying things out, and some of which may just be dependencies you don't want to think about directly) into a list that are clearly dependencies of your application.
Querying the list of installed eggs is what tools like Yolk[5] are good for. Note that for setuptools packages, the setup.py file lists all dependencies. If you develop for e.g. Listen and Plone, you only need to keep track of Listen and Plone.
One of the things that I think is pretty easy with workingenv, and a bit confusing with buildout, is moving one package into development. In workingenv you get the package you want (however you do that -- check out a branch, make your own local repository, unpack a tarball, etc), and you run (after activating the environment) "python setup.py develop". Or if the package isn't using setuptools, "python -c 'import setuptools; execfile("setup.py")' develop". Note that this is actually one of the few places you actually have to activate the environment. And heck, if I just compiled a little something into bin/python then even that wouldn't be necessary. (Maybe even a hard link would be enough, I'm not sure.) In buildout it's a bit more complicated. You can move an egg into develop-eggs, but that relies on buildout finding the right package. That's not really that easy, especially because setuptools only really understands packages being newer or older, it doesn't understand things like branches. It's hard even when you don't have this problem.
- With workingenv, when I run easy_install SomePackage I need to worry about whether I'm actually in the global environment or the workingenv of the instance. That is, workingenv requires activation (putting your shell into a special state where the python environment is the one in your workingenv, until you deactivate it). By contrast, other people may not like the "add to buildout.cfg, re-run buildout dance" that buildout uses instead.
If you use the easy_install script in the workingenv bin/, then you don't have to activate the environment. Very similar to buildout, workingenv scripts contain their path/environment.
- It works in Windows. :) I have no idea how hard it's to make ploneenv work on Windows, but I hope it's not too bad. The scripts Hanno wrote do give us a near-proper zopectl for Windows as well, which is nice. I imagine these could be adapted to be used with plain Zope instances, though. I assume workingenv gives us setuptools script support locally as well.
Support for Windows should be fairly trivial. I would appreciate it if someone (Hanno?) gave it a try. Basically, all we need is the correct way to patch bin/zopectl so that it runs the bin/activate.bat script before startup. We shouldn't seriously consider "runs on Windows" as an argument for ploneout, just because ploneenv hasn't seen a Windows developer yet. :-)
Workingenv does, as far as I know, work with Windows. At least I've received several patches (I've never used it myself). -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Ian Bicking wrote:
One of the things that I think is pretty easy with workingenv, and a bit confusing with buildout, is moving one package into development. In workingenv you get the package you want (however you do that -- check out a branch, make your own local repository, unpack a tarball, etc), and you run (after activating the environment) "python setup.py develop". Or if the package isn't using setuptools, "python -c 'import setuptools; execfile("setup.py")' develop". Note that this is actually one of the few places you actually have to activate the environment. And heck, if I just compiled a little something into bin/python then even that wouldn't be necessary. (Maybe even a hard link would be enough, I'm not sure.)
In buildout it's a bit more complicated. You can move an egg into develop-eggs, but that relies on buildout finding the right package. That's not really that easy, especially because setuptools only really understands packages being newer or older, it doesn't understand things like branches. It's hard even when you don't have this problem.
I think all you need to do is something like this: $ svn co http://myrepo/myproduct/trunk src/myproduct Edit buildout.cfg and add: develop-eggs = src/myproduct (or add it to the list of develop-eggs) $ bin/buildout -o (-o to save time only). As far as I understand, buildout explicitly prefers develop eggs over ones it has found otherwise. So, in other words, you check out the package you're working on (by convention into src/) and then point to the source location in builduot.cfg's develop-eggs option. I don't find that confusing, personally - or did I miss something?
If you use the easy_install script in the workingenv bin/, then you don't have to activate the environment. Very similar to buildout, workingenv scripts contain their path/environment.
Right, thanks for pointing that out.
Workingenv does, as far as I know, work with Windows. At least I've received several patches (I've never used it myself).
Lucky you. :) Having Parallels on OS X is a mixed blessing. :) Martin
Martin Aspeli wrote:
Ian Bicking wrote:
If you use the easy_install script in the workingenv bin/, then you don't have to activate the environment. Very similar to buildout, workingenv scripts contain their path/environment.
Right, thanks for pointing that out.
I should also mention that, with ploneenv[1], you can run bin/runzope or bin/zopectl without having to activate the workingenv first. Daniel [1] http://danielnouri.org/blog/devel/zope/ploneenv-intro.html
participants (3)
-
Daniel Nouri -
Ian Bicking -
Martin Aspeli