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

[Daniel Nouri]

Martin Aspeli wrote:
> 
> 
> 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.

Ah, I thought you meant upload Plone itself without worrying about the
dependencies.  I guess that a script that creates a new release of all
plone.* packages when something in them has changed at release time would
certainly be useful.  I agree, this might be a good exercise for a buildout
recipe.

>> 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.

Totally agreed.

>> 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 like the buildbot idea.  However, for my clients, I try to use as much as
possible from the system's package management system (if it has any ;).
That way, they get security updates for free.

>> 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.

I meant edit locally.  You can see editing buildout.cfg locally as the
equivalent to easy_installing stuff into your workingenv after it's been set up.

You can use the same ploneenv or workingenv commands to also update your
ploneenv/workingenv.  But I guess this won't remove any non-required
packages, unless you tell it so.


Daniel