[Zope-dev] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

[Ian Bicking]

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 at colorstudy.com | http://blog.ianbicking.org