Martin Aspeli wrote:

...

Eggs exist to pkg_resources (the runtime portion of setuptools) simply by being available on a path. E.g., if you have lib/python/ on the path, and lib/python/Foo-1.0.egg/ exists, then if you do pkg_resources.require('Foo') that will add lib/python/Foo-1.0.egg/ to the path, and you can import from it. When you can actually import from the egg it is "active". You can also see its entry points at that time, but not if it is just available.

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. But since buildout controls those directories that would be fine, I guess, assuming you don't put anything in those locations on your own. 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). 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. 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)

Secondly, have you seen this proposal? I'm sure you'd have something to add.

http://wiki.zope.org/zope2/EggifyingZopesExtensionMechanismQuotProductsQuot

zc.buildout also uses entry points for its recipes, and several people have talked about entry points instead of ZCML slugs, so I think things are moving in this direction.

I left some comments over here a while back: http://wiki.zope.org/zope3/ZopeConfigurationEggSupport But that's more about ZCMLy things. Philipp's proposal looks fine to me, though it doesn't seem to address how products would be activated or not (it seems to mention that eggs wouldn't be installed as products by default, but doesn't propose a mechanism to select the products). Because of the difficulty scanning for entry points if the egg isn't activated, I'd advocate sticking to something like enumerating (or blacklisting) distribution names. Then if you have: [zope2.products] CMFDefault = Products.CMFDefault the entry point name "CMFDefault" wouldn't be significant. Or you could select not just distributions, but distributions+entry_point name. In Paste I use egg:Package#entry_point_name (where entry_point_name defaults to "main"). I believe buildout uses Package:entry_point_name, where entry_point_name defaults to "default". If we could all agree on a convention, that'd be nice. I strongly prefer "main", because that's really what I think the unnamed entry point is, not just default -- "default" just refers to the parsing/locating strategy, not the intent. I also would like something that is unambiguously different from a Python object specifier, so that you could take either an explicit object reference or an entry point in the same place and be able to clearly tell the difference. But if we can agree on something and document it, I'm willing to update Paste Deploy to support the new/standard syntax. Ian