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

[Ian Bicking]

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