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

[Ian Bicking]

whit wrote:
>> 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.

I think this is the basic difference -- workingenv is 
development-centric, while buildout is deployment-centric.  This does 
not necessarily mean "the best tool for the job", because focusing on 
development and ignore deployment isn't a good job, nor the other way 
around.

At TOPP we know how to address both stories with workingenv.  We haven't 
figured it out with buildout, despite trying.  And we definitely aren't 
satisfied with just a deployment tool that doesn't address our 
development needs.

But there's a lot of use cases for Plone specifically where carefully 
developing just a deployment solution makes sense.  That doesn't make 
sense for us, because we're not in the kind of consulting business where 
the relative scale of development and deployment works like that.  But 
eh; the presence of a buildout for Plone doesn't hurt our position any. 
  Anything that gets rid of another ad hoc crappy deployment is good by 
me.  And if other people are working on it, all the better!  If *Plone* 
becomes incompatible with workingenv that'd be bothersome (though it was 
not compatible with workingenv without some work in the first place). 
But if a buildout is incompatible, eh... who knows, it might even make 
sense to create something like a "freeze this workingenv as a buildout" 
script.  That one directory structure can't be both at the same time 
isn't a huge problem in my mind.

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

Path names aren't really the problem.  We got a little guerrilla war 
going on over the setuptools' script-generating monkey patches.  We'd 
both probably prefer a proper way to change how setuptools generates 
scripts, but it's not clear that we could really be compatible -- 
enumeration vs. changing the path is a totally different strategy.  I'd 
rather see easy-install.pth become a better package database, or some 
other strategy of external requirement specifications, instead of 
building it into scripts.  I understand the issue Jim is trying to solve 
here, but putting everything into the buildout.cfg and then imperatively 
setting up the files from there bothers me and does not make development 
easy IMHO.

That's mostly the problem.  Then workingenv would do its part by 
monkeypatching distutils and setuptools to install things locally, and 
changing site.py to not automatically pick up things globally.  And 
buildout could do its stuff that applies to other more complicated 
setups than just setting up some libraries, which is about where 
workingenv stops.

Well, what I'd *really* like is an idea of a working environment that 
applies more widely than Python, because other languages (including but 
not limited to the dynamic languages) have all these same problems, and 
we all have half-assed solutions.  But I don't even know how to start 
that conversation.  And don't get me started on how the distributions 
are going to look at all this!

   Ian