[Grok-dev] Re: Grok component reuse in the Zope 3 world (was Re: Re: ANN: megrok.quarry)

[Gary Poster]

On May 5, 2007, at 12:46 PM, Martijn Faassen wrote:

> Hey Gary,

Hey Martijn.

> Even though I argue, I must thank you for bringing this up. One the  
> one hand your insistence that you don't want to use alternative  
> configuration mechanisms makes me less motivated to do the work I  
> had planned, as apparently it will have no effect. On the other  
> hand, it's good to know this in advance so I won't put my hopes up  
> too much. I will still do it as this was about scratching my own  
> itch more than anyone else's anyway.

Let me also try to explain something at the start.  At the end of my  
last email, I said something to the effect of "I don't feel the need  
to argue the points anymore."  Here's a longer way of saying that.

You have certainly given me your attention on this issue, and that's  
all I was really asking for.  I wanted to bring this up now so we  
don't isolate ourselves from one another.  You grok folks are very  
smart, and you, Martijn, have made it clear that you worry about this  
sort of thing.  So even though we don't see quite eye-to-eye, I  
figure the best thing to do now is just wait and see what you all do,  
and hope that I (and others) can use elements of what you produce  
without subscribing to the grok approach itself.

So, the rest of my reply, and debate, is out of politeness, really,  
since you have taken the time to think and write back. :-)  My goal  
has been met as best as I had hoped it to be met, realistically.  You  
know I don't stick my head up in the community too much, and a big  
reason is that I don't have much time at home or work for it.  I  
respect your time too, so I want to "talk back".  But, heh, if you  
don't give another thought-provoking reply in return I won't mind. ;-)

> Gary Poster wrote:
> [argues ZCML is an essential ingredient towards creation of  
> reusable components and that argument is useless]
>
> I think we should agree to disagree on this one. :)

Cool.

> [Grok "combatting" reuse outside the community]
>
> I think the word 'combat' is rather too heavy a term. There's a  
> concern and I hope we can fix the concern, though I don't think we  
> can fix it in the way you want us to.
>
> [snip]
>>> Why do you consider it insufficient? In a package that uses grok,  
>>> I can declare an adapter. Same with ZCML. What's the difference?
>> If you write good Python code I want to reuse, and I don't want to  
>> use grok (or have my package "grokked"), I'd like to be able to  
>> use it without depending on grok.  That's the heart of it.
>
> Do I understand you correctly and do you think *your* package will  
> be grokked if you use a package that is grokked? That's certainly  
> not true. Grok is not a virus that infects other packages.

Nope, I understood that.

> If that's not what you meant, you have to have a reason for not  
> wanting to depend on Grok, or to be more correctly, depend on a  
> smaller configuration library that Grok will be using.

[...]

> * I think the problem might in fact be smaller than you suspect.  
> ZCML statements produce configuration state, just like grokking  
> does. You should be able to produce with ZCML statements whatever  
> registrations that Grok can produce through grokking. You would  
> still need to depend on base classes provided by Grok, though.

So, Grok uses the underlying configuration machinery that ZCML uses,  
with two steps so you can override registrations and detect conflicts  
and so on, and Grok and ZCML manipulate the same data structure in  
the first stage, and therefore ZCML can override Grok registrations  
and vice versa?  If so, hooray.  That would allay many fears.

One that would not be allayed is that, where ZCML allows separate  
files so you can mix and match what you want to import and use, AFAIK  
you can either grok a package or not.  But that's a pretty trivial  
complaint if you are using the underlying ZCML configuration machinery.

I snipped out a lot above and below because the above is basically my  
response to big chunks of it, and I was repeating myself.

>>> Is it because a grok-based component wouldn't include enough  
>>> security declarations? (because in grok you don't need to).  
>>> That's the only thing I can think of. It's a hard one to solve,  
>>> as writing code with a lot of permissions sprinkled around is a  
>>> major pain Grok tries to get rid of.
>> Certainly that's an issue.  Especially given that security changes  
>> can be very important to us, as I alluded above.  If grok security  
>> assumptions pervade a bit of code, it's almost certain that I  
>> can't use it.
>
> I'd argue it's the other way around - normal Zope 3 usage has  
> security assumptions spread throughout the code.

Certainly there are security assumptions spread throughout the code  
that are different than the Grok approach: Grok wants to do security  
on view-level, and everything else in Zope 3 doesn't.  The Grok  
approach is appealing for apps that don't have TTW code, and in  
retrospect might have been a reasonable way to structure the default  
Zope 3 configuration.  Amusingly (to me anyway), though, I actually  
want the current Zope 3 approach, because I actually have TTW code in  
some of my apps.

Doesn't effectively Grok make the same kind of security assumptions,  
but in reverse?  If not, interesting and cool.  Maybe we ought to  
make that switch easier to make in Zope core, then.  As you might  
expect, though, practically, I need it to be easy to keep on using  
the current Zope 3 approach.

Of course, if the Grok-like changes to Zope 3 core would mean, for  
instance, that objects without security assertions would be assumed  
to be playing the Grok way, and so implicitly/automatically allowed,  
that would not be so good for me.

The kind of security assumptions I was thinking of in my original  
comment was assuming a security policy.  Maybe Grok's stuff wouldn't  
make that a problem, but because AIUI you have changed the security  
story it would definitely be a task to confirm that.

> Grok doesn't do security except on the view-level. This means we  
> don't care about assigning permissions in many cases. If you want  
> to use a Grok-based package and care about content-level security,  
> you will have to provide external ZCML to state your permissions. I  
> think that would probably work out of the box, but I haven't tried.

Again, amusingly to me, I'm actually in a position where that would  
be a make-or-break thing.  But yes, if it worked either way that  
would be cool.

> [snip]
>>> It's you who says Grok is about applications and not components,  
>>> not me. :)
>> Hm.  OK.
>>> Grok should also be about components, because otherwise there is  
>>> no easy way to spin off components from applications. This is a  
>>> very important mechanism of component generation. In my opinion  
>>> it would defeat the purpose of Grok if people would have to go  
>>> back to ZCML as soon as they want to spin off a component.  
>>> Spinning off a component should be moving code into another  
>>> package, and the addition of ZCML shouldn't be required.
>> I don't want grok developers to *have* to make some ZCML; but I  
>> don't want grok developers to make nice components that exclude  
>> those of us who continue to choose to use zcml.
>
> I think that is possible right now. If you are willing to dive into  
> a Grok-based package and want to write a lot of ZCML registrations  
> to replace the information in the code then I think you can do that.
>
> It could even be automated - it is possible to write code that  
> sniffs Grok's registration information and produces ZCML. The  
> information is, of course, all there (excepting information we  
> don't need, such as permission information).
>
> I'd argue if you go as far as generating ZCML you can just as well  
> go the whole way and simply use the ZCML 'grok' directive on the  
> package.
>
> Full disclosure: some aspects of Grok may be a bit more tricky to  
> represent in ZCML as they depend on the event system to install,  
> say, the catalog, into an application. I'd say those are usually  
> more application-oriented and less component oriented, so typically  
> won't matter as much for components. This is an area to watch  
> carefully, however.

Yay to watching that kind of thing. :-)

[...skipping more stuff that I feel I already addressed, effectively...]


>
>>>> Second, when the first approach is inappropriate for whatever  
>>>> reason, consider putting the grok glue code in a separate  
>>>> module.  That way someone can import your generally interesting  
>>>> code without depending on grok, or the grok approach.  Perhaps  
>>>> someone else will even add a zcml file, and folks can choose to  
>>>> go the grok road or the zcml road for your package.
>>>
>>> All grok packages already have a configure.zcml file. It just  
>>> contains a single line, telling it to grok the package using the  
>>> only ZCML directive defined by grok, namely 'grok' :). The result  
>>> of including that configure.zcml is the same - component  
>>> registrations. This is why we are already close to reusability of  
>>> grok-based code in Zope 3. Two reasons why more needs to be done:
>> I was trying to be constructive when I suggested that you divide  
>> up your Python grok hints.  That would let you do the kind of  
>> division I said I (we) do with multiple zcml files.
>
> I know your suggestions are well intentioned.
>
> The problem is that what you're asking is not really doable and  
> have Grok still be Grok, as I described above in the case of  
> adapters. I can't separate the adapter registration from the  
> adapter implementation with Grok:
>
> class MyAdapter(grok.Adapter):
>    grok.context(ITheAdapted)
>    grok.provides(ISomeInterface)
>
> But if you wanted to use ZCML to register this adapter, you'd write  
> something like:
>
> <adapter for="ITheAdapted" factory="module.MyAdapter"  
> provides="ISomeInterface" />
>
> and that should still work.

[aside]

In that particular example, isn't that a bit of wheel reinvention?   
These days, I can do the following:

class Foo(object):
     zope.interface.implements(IFoo)
     zope.component.adapts(IBar)

and then

<adapter factory="Foo" />

or similarly

@zope.interface.implementer(IFoo)
@zope.component.adapter(IBar)
def foo(bar):
     # ...

and then

<adapter factory="foo" />

Couldn't grok reuse the standard zope.interface and zope.component  
spellings?

[...again, snipping bits to which I think I effectively replied...]

> You're clearly not forcing us to use ZCML instead of other  
> approaches for our own packages, otherwise we couldn't have written  
> Grok. Why do you think we would be forcing you if you turn this  
> around and you use a Grok-based package?

Well, because, (as I think you acknowledge several times) "you aren't  
there yet".  As I said at the start, I know you guys are smart, and  
since you are working towards this, then yay.  As I said, if you are  
using the underlying Zope configuration stuff that ZCML uses, then  
many of my most significant worries go away.

Thanks again for your reply.  I'll try to make a quick reply to your  
next one too, from my response to Lennart. ;-)

Gary