[Zope-dev] Re: ploneout - Or how using zc.buildout for a common
Zope2 project might look like
tseaver at palladion.com
Fri Jan 26 18:22:30 EST 2007
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
>>>> 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
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
- 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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v184.108.40.206 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Zope-Dev