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

[Martin Aspeli]

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