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@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org