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. 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. 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.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope-Dev maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
