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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
