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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
