[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

[Philipp von Weitershausen]

On 25 Jan 2007, at 23:13 , whit wrote:
>> The point is that buildout *already* handles eggs. There's really  
>> no point for having an extra layer on top of buildout. The  
>> zc.recipe.egg recipe can install any egg (as a development one or  
>> not) in an automated fashion, which is exactly what you'd want  
>> from a buildout.
>>
> well that's awesome that buildout has duplicated this effort....

It didn't. buildout interfaces with setuptools and easy_install to do  
its job. The stuff buildout adds is the recipe abstraction so that  
the installation can be automated over and over again.

>>> the "source bin/activate" dance is the only thing I see being a  
>>> detriment here(and with the latest workingenv, your shell prompt  
>>> lets
>>> you know you are in an env).
>>
>> Not everybody likes the activate dance. With buildout, you don't  
>> need it. The recipes make sure that the scripts that get installed  
>> into the buildout's 'bin' directory have the right PYTHONPATH set  
>> and have access to the eggs you requested for the buildout.
> is there really a difference between zopectl and source bin/ 
> activate?  I guess the main difference here is where PYTHONPATH  
> gets set and how people work with it.   for example, if you just  
> start python and want to play with code.... sounds like with  
> zc.buildout you are out of luck for things installed in the buildout.

Possibly, yeah. That's one thing I like about workingenv...

> In our situation, we might have multiple versions of software  
> running on different processes started in different workingenv  
> (often not even using zope).    being able to contextualize the  
> python path is a useful development tool; this is understandable  
> for buildout to avoid(as a deployment tool), but if we are  
> considering using buildout as a prescribed way for people to manage  
> their development environments, it seems lacking.

You're right, this might just be one of buildout's sore spots, though  
one that could potentially be fixed. I wonder what it'd take to  
produce a buildout recipe that added an "activate" script like the  
one workingenv has... it seems almost trivial.

>>>> Workingenv made it more complex than it needed to be (or  
>>>> buildout did, depending on which perspective you look at it  
>>>> from). I believe Hanno wanted to rescue the recipe in case  
>>>> others found it useful, but it's not used for now.
>>>
>>> what about if I'm already using workingenv... and want to use  
>>> zope or plone in my workingenv?
>>
>> I see no problem with that. zc.buildout is one way of deploying  
>> Python software like Zope. As long as you've got eggs, you could  
>> install them manually into your workingenv just fine. buildout  
>> just does it an automated fashion (and, of course, it can do more  
>> than just installing eggs).
>>
> which I could automate in my env (workingenv takes recipes also).  
> for that matter, eggs automate the installation of eggs...

Yup, you're right. Note that buildout does more than just installing  
eggs, though. It can automate potentially anything). I find the  
zc.recipe.cmmi recipe quite powerful, it can build any Unixy software  
(e.g. Python, libxml, ...) using "configure; make; make install".

> I'm not sure what it would take to make buildout just automate  
> install eggs into my  env... but not putting them in special  
> directories would be a start.

As said, I agree.

>>> currently, I don't see an easy way to use buildouts inside a  
>>> workingenv, whereas the rest of python world works great.  I will  
>>> have alot of trouble explaining to my developer who already think  
>>> zope smells that they have to change the way they work to use  
>>> zc.buildout recipes.
>>>
>>> for example, I can't use the deliverance or lxml buildout with an  
>>> existing topp.deploy workingenv because of buildout's arbitrary  
>>> egg handling scheme.  If zc.buildout didn't try to do so much,  
>>> the python would be installed transparently like everything else  
>>> I easy_install.
>>
>> I'm not too fond of zc.buildout's directory scheme eiher. In  
>> particular, I wish that it would use 'lib/python' instead of  
>> 'eggs' and 'src' instead of 'develop-eggs'. I don't know enough  
>> zc.buildout details to be able to say whether that can be chagned  
>> by remimplementing the egg installation recipe. I would sure hope  
>> it is.
> +1
>
> this may be all that is required to make the two play well together 
> (or have buildout respect an existing workingenv when doing it's  
> local install of eggs).  Maybe it's just a matter of zc.buildout  
> seeing workingenv is in effect and not composing special pythonpaths.
>
> harmony is my interest here. workingenv is pretty low-level and  
> works hard to work well with python. there is no reason that  
> zc.buildout should have a problem with that.. it just needs to do  
> less when appropriate.

Well, it seems they already can work together, given Hanno's  
implementation for a workingenv recipe. The question is whether it  
makes sense. If you're primiarly interested in the automated  
installation of eggs, it seems workingenv is just another unnecessary  
layer (or buidout, whichever way you see it).

>>> as stated before, I don't mind using zc.buildout, but I don't  
>>> want to have to learn zc.buildout to use it meaningfully in my  
>>> existing setup. If a buildout recipes could be executed by  
>>> themselves(like buildout-zope2, buildout-deliverance, buildout- 
>>> squid) as well as by aggregated recipes.  This would make  
>>> buildout a killer tool inside my workingenv rather than a choice  
>>> I had to make between two technologies.
>>
>> As said already, I think once you've got buildout, there's no need  
>> for workingen, except if you think that "Zope stinks" ;)
>>
> ooooooh philip...
>
> <rant>
> you're drawing my ire for taking a stereotypical stone-age  
> isolationist zope developer attitude toward the rest of the world.   
> shame on you(though I don't think you really mean this. so take  
> this as feedback).

No I didn't mean it. Perhaps adding that little tongue-in-cheek there  
was a mistake, I certainly didn't want to cause a rant there...

I spoke from a technical point of view, based on the fact that  
workingenv and buildout have a lot of common features. Using both at  
the same time seems like double trouble to me (adding unnecessary  
layers, etc.). Perhaps it isn't, perhaps it makes total sense (you  
certainly seem to have a point with the Python interpreter). All I  
wanted to say is that if you guys get good mileage out of workingenv,  
I think you should keep using it. Why couldn't Plone be deployable in  
either a workingenv setup or a buildout? I don't think we ever have  
to make an exclusive decision for either one.

As for kool aids and smelly things, the general reaction I get from  
people I show workingenv to is mixed as well (I quite like it myself  
and am more familiar with it than buildout). Not everyone likes the  
bin/activiate script and the prompt maniuplation either. Yes,  
workingenv might be lighter on the kool-aid, but it's not like  
zc.buildout is a big pile of magic, either. And in particular, I  
don't think zc.buildout tears down a lot of bridges. In fact, a lot  
of the things I see in it seem like they were done the way they are  
done in order to use existing bridges (eggs, Unixy applications, heck  
even using ConfigParser instead of ZConfig...)


As a pure *consumer* of both workingenv and zc.buildout, I haven't  
yet reached the zen that I'd like to have to suggest the best way  
toward harmony, but I would love to discuss ideas at the Camp5 sprint.

Philipp