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

[Martijn Faassen]

Hey Martin,

Martin Aspeli wrote:
[snip]
>> A *plugin* that plugs into Grok and Plone? Could you give an example 
>> of such a thing? I have a very hard time imagining what that could be.
> 
> Perhaps I'm inventing use cases that don't exist. It's more a gut feel 
> that limiting ourselves to exactly one "target" forever may be something 
> that we come to regret.

I don't consider it a disaster if we maintain 'target' and should other 
targets be needed in the future in what looks like rare cases now, we 
add some other pattern that allows you to add more targets along the 
lines of what Ethan spelled out.

[z3c.autoinclude.plugin]
target = plone.app
target[zope2] = zope2

I really hope that this is actually not a real use case, for reasons I 
explain below.

[snip]
> When you install a third party product, having to add 
> a slug or an include in your own package (if you have one - 
> non-programmers using Plone don't) is just lame. :) Some plugins may not 
> be Plone-specific or may have some specific Plone support but be 
> applicable to Zope (2 or 3) or CMF or Grok or whatever in general.

That's a good point, but I think Plone should take care to load up these 
extra plugins as well. I.e. if Plone accepts CMF plugins, it should just 
have a directive in its ZCML to auto-include those as well (or CMF can 
have this).

>> [snip]
>>  > I can certainly see situations where you have
>>  > an auto-includable package that works with Plone and Grok, but 
>> where the
>>  > configuration is slightly different for each.
>>
>> Loading up dependencies we already have covered with the autoinclude 
>> directive.
> 
> I didn't mean that. I meant a situation where a package works in plain 
> Zope 2, say, but has an optional view or module that's mostly useful in 
> Plone. The ZCML configuration may need to be adjusted slightly for the 
> two different targets.

I can imagine a design where we load up an extra plone.zcml file if it's 
there too. I don't think this is a good idea though.

I think a Zope package with optional Plone stuff should typically be 
*two* packages - the Zope one, and then a Plone specific one that 
depends on the Zope one. Having an "optional view that works best with 
Plone" is a recipe for evolving the package to "it only works with 
Plone" anyway (I've seen this happen). Splitting it up into multiple 
packages is just plain good engineering.

I know that some people use ZCML in a very different way and have 
fundamentally different ZCML files for the same package, and are really 
adamant we should not get in the way of this use case. I think that's 
all we should do: not get in the way (the directive doesn't *have* to be 
used), but otherwise not worry about it - they're going to include their 
ZCML manually anyway.

[snip]
>> I think we should indeed say YAGNI for a while and see how this works 
>> out for Plone. When real-world problems come up, we will come back and 
>> talk about adding behaviors.
> 
> So long as we don't design the syntax or framework so that it's 
> impossible to cleanly support multiple targets in the future, I'm happy 
> with that stance.

I am still hoping we're not going to need this feature at all. I also 
don't see us locking ourselves in anyway. We can do the syntax spelled 
out above if it really should be needed later, or just come up with a 
whole new entry point that supports this should this become necessary.

Regards,

Martijn