Tres Seaver wrote:
I don't think buildout's default locations would be called "sensible" by
anybody except the folks who wrote it.
I think a lot of this may have to do with sensible defaults; most (all?)
of this is settable via options in buildout.cfg, which is reassuring at
least.
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)?
I'd tend to agree that that'd make sense. I think for ploneout's
buildout.cfg, we may set the option accordingly.
- Why not put development eggs in a directory which matches existing
conventions ('src')?
At least as it's used in ploneout, the development eggs are in src/ and
when they're installed, you get .egg-link files in development-eggs. We
may again put that into lib/python for ploneout's purposes.
- 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.)?
Where would a Zope 2 instance or a Zope 2 checkout sit? I thinks parts/
is as good as anything here.
For the z2c.recipe.zope2filestorage (which manages the location of
Data.fs) recipe I've just made it so that it uses 'var' instead of parts.
- 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'?
Hanno is working on a recipe to let us get the zope instance start/stop
script in the top level bin for ploneout. There's already a recipe for
running tests from there. Philipp was of the opinion that you shouldn't
have to care about anything inside parts (it's buildout's playground)
and I'd like to make it so that this is the case.
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
I would agree that having to mangle multiple scripts is annoying. On the
other hand, I find the activate/deactivate dance annoying. I rather
think that the scripts that buildout has created should not require any
special activation or introduction to a particular environment.
Perhaps a solution is to let buildout put things in standard places (as
I'm typing this, we now have all the ploneout .egg and .egg-link
files/directories in ${buildout}/lib/python) and then have an optional
workingenv at the root of the buildout that could be activated when you
want that, but let the buildout-managed scripts (e.g. zope start/stop
and test runner) not require this?
I have a feeling there's more to this than agreeing on directory layout
though. But I hope it oughtn't be *that much more*.
Martin
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
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 )
