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

[Martin Aspeli]

>>  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*.

I did some experimentation with this. Basically, I did:

  - make egg-directory and develop-egg-directory in buildout.cfg be 
lib/python2.4 (which is what workingenv uses)

  - run the buildout again

  - create standard workingenv (python workingenv.py .) in the root 
buildout directory

The results are fairly encouraging:

  - buildout-installed eggs don't work in the workingenv jail...
  - ...but they do if I manually add them to lib/python2.4/easy_install.pth
  - easy_installed packages (i.e. installed with workingenv's 
easy_install) are available to zope

This was only a brief test, but seems to me that if buildout was 
managing the easy_install.pth file we wouldn't be a million miles off 
something where the source bin/activate dance was optional and would 
work as a generic solution, but would not be required for zope's startup 
and other buildout-managed scripts.

However, I'm not sure whether and how buildout should manage 
easy_install.pth in a non-hacky way. A hacky way would be to have a 
buildout recipie that, if included, would just patch that file up based 
on buildout['buildout']['eggs'] (i.e. the list of eggs listed in 
buildout.cfg under the main [buildout] section).

I don't really understand the purpose of easy_install.pth and why it 
matters here, though, so suggestions welcome. :)

Martin