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

[Martin Aspeli]

Daniel Nouri wrote:

>> This is probably a place where the buildout.cfg approach makes sense -
>> we would be able to edit this file so that at any point in time it
>> pointed at the right eggs to construct a Plone release. We could then
>> let buildout run additional recipes that would e.g. run the tests and
>> then create eggs, upload them to the cheese shop, and/or roll tarballs.
>> We would code that in python and package it as buildout recipe eggs.
> 
> I think we should use tags and use the Plone egg to accomplish that.
> Setting the svn:externals etc on the tags may well be scripted, but a recipe
> for uploading to cheese shop or roll tarballs is certainly overkill, since
> setuptool lets you do all that with one line.

But when we have dozens of eggs, it's dozens of lines, no? Or can it 
also upload all dependencies?

Similarly, I think we will need some kind of tarball, so maybe we could 
have a recipe for that. Or not, I mean, it's not difficult to make a 
recipe if it saves time (basically, you just need an entry point), but 
if we don't need it, all the better.

> I'd put everything into $INSTANCE_HOME == $WORKING_ENV.  I don't think
> that's particularly nasty.  As for C libraries, I would probably compile
> those --prefix'ed into $INSTANCE_HOME as well.  Of course, if I have more
> than one Zope instance, I'd split libraries and instances, so that all
> instances can share the libraries.  I know that with buildout this is easy,
> but it's not particularly hard without it either.

Of course. If I had ten customers all with slightly different 
configurations, though, I'd like to have ten self-contained environments 
that I could deploy independently. I'd also like that to be automated so 
that six months down the line, when I had to fix a bug, I could 
understand exactly what the configuration was (I've had problems with 
this before where, for example, I've upgraded my "main" Zope instance or 
"main" Plone checkout and found that it broke stuff but I didn't know 
what it used to be).

I'm not saying that type of thing can't be solved with workingenvs or 
other solutions, I'm just saying that buildout has decent conventions 
that create an environment that's environment self-contained (unless you 
tell it otherwise, e.g. by referring to a common zope instance, but you 
can then switch it back to self-contained again by changing an option in 
the file). Sometimes this may be attractive.

> Right, I never use the Zope from Debian for the same reasons.  But I do like
> to have one Zope 2.10 checkout for all projects that use it.

Yeah, me too, at least for when I develop things that are generic 
components bound for the Collective, or different versions of Plone 
itself. I think for a customer project, I'd prefer to have everything in 
one single directory. But that's down to preference, of course. I do 
think it's nice to have the option of having Zope downloaded and built, 
though, also for things like continuous integration servers (buildbots).

> I think this comes down to a question of discipline.  If you want all your
> developers to use exactly the same environment, then tell them to not
> install anything besides the --requirements, similarly to: "don't edit the
> buildout.cfg".

Well, yes, but if one developer does edit buildout.cfg (we added a new 
requirement or a new step in the build process), everyone else svn up's 
that file and runs bin/buildout and their environments are the same 
again. The --requirements file is, as far as I understand, a one-off 
bootstrap.

Martin