[Grok-dev] Re: Salt & z3c.autoinclude

[David Bain]

I've been lurking on this thread but I'd have to say I think
autoinclude is a more descriptive name.

I like salt, but understand why autoinclude makes more sense.

On Fri, Mar 21, 2008 at 4:24 PM, Ethan Jucovy <ejucovy at openplans.org> wrote:
> On Fri, Mar 21, 2008 at 11:47 AM, Martijn Faassen <faassen at startifact.com>
> wrote:
>
> > I don't see that you should have to spell out the dotted name of the
> > plugin package though: I see entry points contain a 'dist' attribute.
> > Couldn't you use this information?
>
> Ah, I never noticed that, but that looks good.  So scratch what I said about
> containing no information about their provider.  :)  This should work fine.
>
>
> > The right hand side needing something importable seems like a more
> > troublesome problem. Then again, a plugin to an application will almost
> > certainly have a dependency on that package, so a plugin for Plone will
> > depend on Plone and import things from it. This means we could do the
> > following:
> >
> > [z3c.autoinclude.plugin]
> > target = package.plugged.into
> >
> > For plone (if it's in 'plone.app'):
> >
> > [z3c.autoinclude.plugin]
> > target = plone.app
>
> This concerns me, because I've already broken this assumption in my own code
> while using my previous incarnation of salt.  I've actually found it useful
> to be able to create a plugin package which *doesn't* technically require
> the base platform, by putting the entire integration layer (declared
> interface implementations, utility hookups) in ZCML.
>
> On the other hand, I just did a quick hand test, and it appears that the
> entry points aren't actually evaluated when the egg is installed.  So it's
> only when you load() an entry point that the object it refers to must be
> __import__able.  The entry point is only load()ed during execution of the
> <includePlugins> directive for that platform.  So I think it's reasonable to
> assume/enforce that the "target" package is present in the environment at
> the time that the plugins are loaded.
>
> All that said, I do still have a lingering hesitation about this format; it
> just seems to be a bit of an abuse of entry points and a deviation from
> their standard use.  It will work though (thanks for noticing the dist
> attribute) so I'm willing to go along with it.
>
> egj
>
> _______________________________________________
>  Grok-dev mailing list
>  Grok-dev at zope.org
>  http://mail.zope.org/mailman/listinfo/grok-dev
>
>