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.
> 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
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
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.
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
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -