-----BEGIN PGP SIGNED MESSAGE----- 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 puzzling: - 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. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFuo01+gerLs4ltQ4RAj6cAJ4vZ0K6hHhRbLuRuXWyqT/KiVDMUwCeLLMw SVjCFguTUapLe4funr7Ov1I= =68uB -----END PGP SIGNATURE-----