[Grok-dev] Re: Grok naming issues.

[Martijn Faassen]

Hey,

Lennart Regebro wrote:
> Godefroid raised an issue that had us thinking here.
> 
> If I wrote a simple module for five.grok it could most likely work
> under Proper Grok as well. However, because it's called five.grok, it
> will fail on the import "from five import grok" where Grok wants just
> "import grok". So to have more modules that work under both we could
> fix the namespace so that you do "import grok" under five.grok as
> well. (We tried that quickly, it did work fine). This would also means
> that a module that has say, some sort of global utility written for
> grok would work under five.grok.

Uh, magic to make it say 'import grok' in code that doesn't use Grok 
sounds like a really bad idea to me. Far too much magic.

Code that is written for grokcore.component will work under both 
already. So if you're only using those parts, use that.

> However, there is a couple of issues with this:
> 
> 1. plone.grok would either need to have it's plone specific grokkers
> under a different namespace (but that would hinder grok simplicity),
> or patch its grokkers into the grok namespace, which is ugly.

I don't see how it matters for grokkers under what namespace they are. 
It only matters for the components (base classes) that are being grokked.

I think the name "plone.grok" is probably not a good idea. The name 
"grok" implies that there are base classes you can import from it to 
inherit from, so that your classes will be grokked. It implies that 
there's some form of compatibility layer with grok. That's true for 
"five.grok", but not, as far as I understand, for "plone.grok". I think 
it shouldn't be called that way.

If there are to be Plone base classes that are to be grokked that are 
not already defined somewhere else, place them in another namespace that 
isn't called "grok". It's not a compatibility layer. I think in many 
cases you'd write grokkers for existing Plone base classes instead, though?

> That can be fixed by making a generic function for registering things
> in the grok namespace (possibly using grokkers). Any component in
> grokcore.components, five.grok or plone.grok could be registered in
> grok namespace.

No, no, ugly, scary, confusing.

I think we should absolutely should avoid special namespace 
manipulation. Namespace manipulation is a recipe for confusion for 
everybody. I've had my fill of namespace confusion when I ran into 
"PyXML replaces the 'xml' namespace in the standard library" issues. 
It's a form of monkey-patching and therefore should be avoided.

> 2. People who want to use Grok under Plone or Zope might add "grok" as
> an egg in their buildout, which would install Zope 3 and break
> everything

People shouldn't add grok as a dependency if they're not using Grok. :) 
Anyway, this kind of breakage is hardly a huge risk; it's something a 
developer might try and figure out very quickly it's not a good idea.

> That would be fixed if and when we ship plone.grok with Plone (and
> maybe five.grok with Zope 2.12), and that would in that case be a
> temporary issue.
> 
> Opinions on this? Better solutions? More drawbacks benefits with the
> different attitudes?

My strong opinion is that we *don't* want to do any namespace 
manipulations. No magic.

With Grok, we're moving bits of Grok out into their own packages, such 
as grokcore.component. These are intended to be usable independently 
from Grok. Grok will import base classes from these other packages to 
retain compatibility and a simple unified interface.

If you want to use the equivalent of the Grok base classes in Zope 2, 
don't import from "grok" ever, import from five.grok. "five.grok" brings 
Grok base classes to Zope 2, either by reimplementing them in Zope 2 
terms, or by just reimplementing their grokkers, *or* by importing them 
from common base packages such as grokcore.component. Naturally we'd 
like to do more of the latter than of the former, and want to work in 
that direction of supporting more of that in the future.

Maybe one day "grok" as a package will run under Zope 2, unchanged. 
Until that day, supporting "import grok" in Zope 2 is a lie we don't
want to tell.

Now to the original use case: being able to write code that works under 
both 'grok' and 'five.grok', where you cannot use "grokcore.component" 
as you need more than adapters and global utilities.

I think it'd be fine if packages that tried to do this had a loud and 
clear signal that this is their intent:

try:
   import grok
except ImportError
   from five import grok

I can see abstracting this away into a special "grokcompat" package 
somewhere that did this. Then you can write code that does:

import grokcompat as grok

I think that having this loud and clear warning that this code is 
supposed to work under both five.grok and plain grok is actually good to 
have there. It's unlikely that *all* code that uses Grok is going to 
work with "five.grok" any time soon, after all. It's therefore, I think, 
an illusion to want to use packages that use the real grok under Zope 2 
unchanged.

As to what to place in the 'setup.py' of a package that uses 
'grokcompat': I don't know.Perhaps nothing would be the best.

Regards,

Martijn