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

[whit]

Philipp von Weitershausen wrote:
> whit wrote:
>> Martin Aspeli wrote:
>>> Philipp von Weitershausen wrote:
>>>
>>>> This is awesome, and by that I don't mean the fact that we have a 
>>>> plone buildout, but that we actually have Zope 2 recipes for 
>>>> buildout. I hope they can be moved to svn.zope.org for further 
>>>> development to benefit the whole Zope 2 community.
>>>
>>> I believe this is just a matter of contrib agreements being sorted 
>>> out (Hanno?). I guess I need to get mine sorted out as well if I'm 
>>> going to keep working on this when it moves... :-/
>>>
>>>> I also see that workingenv was abandoned. That's very good to hear 
>>>> because buildout has a lot of machinery for installing eggs 
>>>> already, it would just've been duplicated with workingenv...
>>
>> is there some advantage to the way that buildout handles eggs over 
>> workingenv. as I understand it, workingenv *only* handles python 
>> setup and does that well and transparently.
>
> 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....
>> 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.

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

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. 

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

who did I say thinks zope smells? my developers(the people I have manage 
and work with)...

who as non-zope python programmers are rightfully a little leery of zope 
kool-aid and whether it's worth their time, and like using workingenv as 
a python development environment.  Telling them that there is no need 
for workingenv is not acceptable and they should just use new way X 
because some really smart zope guys think it's great really doesn't fly; 
they are already happily using it and just want to install stuff they 
need into where they are working now. 

I get really tired of defending zope world tech and things like this 
*don't* help.

you can't build bridges by telling people to burn their old ones.  let's 
put this way, in the democratic hierarchy that is my work place, I have 
to justify zope and every other technology we use and these are the 
kinds of battles that loses the zope community developers. 

try to justify why a zope hammer is better and why zope folk keep 
building new hammers that don't play nice with everyone else's hammer 
loses us cred.   Credibility is something my job depends on as does the 
job of everyone who has to make technology decisions and has to stand by 
them.   Pointing at zc.buildout and saying it handles eggs and i should 
just rebuild the basis of all the deployments ten developers are working 
happily and effectively on makes me look like an idiot.  

next time we decide whether to write a zope app or something else, I'm 
probably not going to have much of a say.

</rant>



-w



-- 

------ d. whit morriss ------
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975           -

"If you don't know where you are,   
 you don't know anything at all"                                             

Dr. Edgar Spencer, Ph.D., 1995