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

Tres Seaver tseaver at palladion.com
Fri Jan 26 18:22:30 EST 2007

Hash: SHA1

Jim Fulton wrote:
> Ian Bicking wrote:
>> 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.
> Certainly buildout encourages the use of eggs.  I think we're all moving
> toward the use of eggs pretty aggressively.
> Of course, a Zope installation, most notably instance creation, has
> requirements beyond the scope of eggs.  Buildout addresses those
> requirements.
>>>> 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 ;)
> And buildout is one such tool.
>>>> 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.
> No, the user controls the directory of eggs using easy_install, workingenv, or
> buildout.

I don't think buildout's default locations would be called "sensible" by
anybody except the folks who wrote it.  Here is some of what I find

  -  Why don't binary eggs go in one of the "standard" location
    (lib/python or lib/python2.x)?

  - Why not put development eggs in a directory which matches existing
    conventions ('src')?

  - Why are pieces of the buildout squirreled away under 'parts',
    instead of putting them in a location which signals their purpose
    ('lib', 'libexec', 'var', etc.)?

  - Why do I have to cd down into 'parts/instances/foo' to run the
    application which is the point of the buildout, rather than running
    scripts from 'bin'?

The perplexing filesystem layout was one of the biggest strikes against
zpkg:  it feels as though buildout has some of the same heritage.

>  easy_install goes further by creating .pth files.  A .pth contains
> a single static path.  This is really no-different than a single static path
> baked into a script by buildout.

Except that *any* script running in that enviroment has access to the
paths set up by *all* the egg installations:  adding a new egg doesn't
require touching the scripts.

>  In both cases, the user has some control
> over how this path is baked.  I chose to include the path in the script because
> it makes the script more independent of it's environment.  Once created, the
> script can be moved or linked anywhere and run from anywhere without any
> brittle rules for finding the .pth file.  Phillip Eby suggested that script-
> dependent .pth files might be put alongside the script, but I think just
> including the path in the script is cleaner.

For deployment, perhaps, but you have to munge *each* script when you
add a new egg in development, rather than letting setuptools tweak the
.pth files (which are the "standard" Python path extension mechanism).
It is therefore *much* harder to "try out" a new egg in a buildout
environment, using easy_install / setuptools, than in a workingenv (or
the environment created by 'virtual_python', which is what I use on a
day-to-day basis).

 I don't have a usecase for executing the scripts with any python
interpeter other than the one which ran setuptools to generate them, and
therefore don't care for the hard-wired path manipulation

- --
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Zope-Dev mailing list