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

[Jim Fulton]

Ian Bicking wrote:
> Martin Aspeli wrote:
...
>>> If lib/python/Foo-1.0.egg/ is on the path to start with you can 
>>> import from it directly.  
>>
>> This is what zc.reipe.egg does I believe.
> 
> It activates (i.e., adds eggs to the path) in the scripts.  I think 
> setuptools' egg activation will be superfluous at that point, because a 
> complete and consistent set of eggs is activated up-front. 

Yup

 > I'm not even
> sure if you can activate any extra eggs (that might be available on 
> eggs/ or something) at that point, because the containing directory 
> isn't on the path. 

Right.  If you had the need to do that, you would need to list it
or some other location on the path, which the relevant recipes
let you do.

 > But since buildout controls those directories that
> would be fine, I guess, assuming you don't put anything in those 
> locations on your own.

It doesn't exert that much control.  That is why the eggs directory
can be shared.  If buildout adds an egg link, then it will remove it
when the corresponding directory is removed from the develop option.

Side note: Unlike setuptools, buildout prefers develop eggs over
non-develop eggs.  If there is a develop egg that matches a requirement,
it will use it.  This is to make development easier.  A common pattern
for me is that I use a regular egg and find a problem with it.  I
temporarily check its source out into my buildout and add it to the develop
option.  When I've made necessary changes, I can make a new egg and switch to
that. At that point, it is important to remove the develop egg link.
This happens automatically when I remove the project check out from my develop
option.

> In that way I suppose lib/pythonX.Y/ would be a misnomer of sorts, as 
> eggs/ is just a storage area for eggs that are managed elsewhere (in 
> buildout.cfg).

Yes

> OTOH, easy_install and setuptools generally has no problem dealing with 
> eggs that *aren't* on the path, if you use a .egg-link or .pth file to 
> point to the egg (preferably both).  So while Jim hopes to have a 
> centrally located repository of eggs (where buildouts only draw on a 
> subset), this is already possible using setuptools' conventions. 

Except with setuptools conventions, this repository has to be in
your Python install, or be in some directory that you specify in
some inconvenient way that setuptools is willing to pay attention
to.  workingenv overcomes this in various ways.

> Then 
> lib/python could become

?

> (BTW, existing Zope 2 stuff often seems to prefer lib/python/ over 
> lib/pythonX.Y/, for reasons I don't really understand -- it basically 
> prefers the distutils --home option over the --prefix option.  So using 
> workingenv with Zope I use workingenv.py --home, which sets up the 
> environment slightly differently)

This is an example of Zope trying to follow conventions. This goes back
to early versions of Python that used lib/python rather than lib/pythonX.Y.
This is one reason that I don't find following these conventions to be all
that useful.  There's also the fact that this convention is Unix specific
and leads to annoying nested directories where the nesting provides no
real value.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org