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

[Ian Bicking]

Jim Fulton wrote:
>> If *Plone* becomes incompatible with workingenv that'd be bothersome
> 
> I agree.
> 
> 
>> But if a buildout is incompatible, eh... who knows,
> 
> I would hope that buildout would not have to be compatible with 
> workingenv, whatever that means, in order for Plone to be compatible.  
> Then again, I'm not sure what compatibility means in this context.

It would be a concern if, for instance, Plone started depending on 
buildout recipes for installation, without "plain" distutils recipes. 
Of course right now there are no distutils recipes for old-style 
Products.  So actually it's an active issue -- if buildout enables Plone 
to keep from moving to distutils/setuptools/egg-style package deployment 
(because buildout is flexible enough to support the old patterns) then 
that would make it harder for workingenv.  But I don't think anyone is 
proposing that buildout means that Plone (and Zope 2/Five) shouldn't 
continue its move towards traditional Python packaging.

So basically I would just hope that Plone doesn't lean to heavily on 
buildout.

>> 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.
> 
> Deployment involves far more than getting the software installed.

Yes; in a workingenv model you start with an environment, then you 
actually make your deployment using tools of your choice.  workingenv 
doesn't deploy for you.  Admittedly "your choice" isn't always good, 
because maybe you didn't want to make a choice ;)

>> 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.
> 
> Um, we're both changing the path -- just in different ways.

Maybe "enumeration vs adding a directory of eggs" is a better 
description.  Setuptools controls the directory of eggs (via 
easy-install.pth), while buildout controls the scripts and doesn't give 
setuptools that control.

>>   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.
> 
> We certainly disagree there. OTOH, I wouldn't be opposed to having a 
> recipe for generating scripts that used the .pth files created by 
> workingenv.

I'm not sure what the problem would be?  I appreciate the desire for a 
set of requirements that is different from the requirements of the 
package, and workingenv has some support for that (with the 
--requirements option), but it's a different style from buildout. 
easy-install.pth would almost be okay, except for the fact that it is 
constantly pointing to things that don't exist, has setuptools' hacks in 
it (to work around the atrocious Python standard site.py), and doesn't 
describe intent, it's just an enumeration of what is available and 
"activated" (i.e., available without specifically requiring something).

Besides all that, it's still a workable foundation IMHO.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org