[Grok-dev] Re: Grok sprint for PyCon 2008: grokcore

[Philipp von Weitershausen]

Brandon Craig Rhodes wrote:
> Thanks for the advice, everyone!  I've decided to indeed host a Grok
> sprint here at PyCon 2008 that indeed attempts to break out a
> "grokcore.*" set of packages from Grok that makes its component
> registration features available individually.
> 
> Everyone, come to our orientation on Sunday afternoon even if you
> can't stay!  We'd love to see you and get your ideas on our approach
> even if you can't stay to type anything in with us.
> 
> We can go ahead and start a prelimimary thread on my approach.  Would
> the following work, as a useful first step?
> 
>  (1) "svn cp" the "grok" package to something called "grokcore.component"

Sounds ok to me. Just note that you're going to end up removing a hell 
of a lot more than you're actually keeping. It may still be a sensible 
way to proceed if you want to save yourself the time of creating a 
separate project etc. Back when I did this on a branch, I just created a 
grokcore.component package within the same buildout to save myself that 
hassle.

>  (2) Remove all tests that don't directly concern component
>      registration.  This should be a *great* activity for new
>      sprinters, since it will let them read lots of well-constructed
>      unit tests without requring them to write any code.  They're just
>      helping us scan the directories of tests to see which belong in a
>      first, minimal implementation of "grokcore.component".

You also want to remove all the grokkers that don't have anything to do 
with adapters, utilities or subscribers. Essentially, you're only going 
to be left with

* the Adapter, MultiAdapter, GlobalUtility base classes from components.py

* the GlobalUtilityDirective, GlobalUtilityInfo from directive.py

* the AdapterGrokker, MultiAdapterGrokker, GlobalUtilityGrokker, 
SubscriberGrokker, AdapterDecoratorGrokker from meta.py

* decorators.py

* and the relevant tests obviously.


As I've suggested in my previous email, you should also consider moving 
all the abstract stuff that has to do with configuration away into a 
separate package called 'grokcore.config' (you could make it live in the 
same buildout for the time being). 'grokcore.config' would contain:

* zcml.py and meta.zcml, which contain and configure the <grok /> ZCML 
directive

* the grok.testing.grok() and grok.testing.grok_component() functions.

Why? Because every grokcore.* package will need this functionality, but 
they won't necessarily need to depend on grokcore.component for this.

>  (3) Even that small set of tests will fail, since all the import
>      statements in the code say "grok" and now need to say something
>      that starts with "grokcore".  We'll therefore each take a .py
>      file or two, jump in and repair the imports, and get the test
>      suite running.  Again, a simple and useful task for beginners.
> 
>  (4) We'll now have a "working" "grokcore.component" that's
>      essentially all of "grok" but renamed and with a smaller test
>      suite.  As the final major step, I can send the volunteers
>      through each .py file, each experimenting independently to find
>      out what can be removed and disabled without breaking the basic
>      ability to run the adapter test suite.  At the end of a day of
>      work, I believe, we could have a very lean "grokcore.component"
>      that just had the component-registration stuff left inside.

Yup. Note that there's one minor complication: grok.Model and 
grok.Container mustn't be part of grokcore.component. Yet they are 
chosen to be the default types of contexts by the ContextGrokker. 
Therefore this grokker also mustn't be part of grokcore.component. Thus 
your test suite will have to provide the tests with a similar kind of 
grokker and a dummy Model class (because some adapter and subscriber 
tests will test the implicit configuration of a context).

>  (5) If we got this far, the last step would be to start a new branch
>      of "grok" in which we remove the component-registration code that
>      now duplicates what's in "grokcore.component", and teach mainline
>      Grok to pull the same functionality from there.

Yup, not forgetting grokcore.config. Grok's meta.zcml would simply 
<include package="grokcore.config" file="meta.zcml" /> and everything 
would stay the same (grok/zcml.py would go away).

> My guess is that one or two major obstacles would come up during the
> above steps that would pause us, but I'm still hopeful that it could
> fit the days of the sprint and the availability of people.  From PvW's
> comment earlier, I'm tempted to pull the Grok test stuff out of Grok
> and into a "grokcore.test" module, since it would be pretty pointless
> to have "grokcore.component" turn around and depend on Grok. :-)
> (Maybe that's what PvW meant and I just didn't grok all that he
> said...)

It's not exactly what I meant. What I meant was to create 
grokcore.config. Having a testing harness that's common to all 
grokcore.* package is probably a good idea, but perhaps a bit premature 
to create. In anycase, following all our naming conventions, it should 
be called grokcore.testing. The module/packge name 'test' is discouraged 
anyway due to Python's test.py in the stdlib. That's why the convention 
for unit tests is to create a 'tests' package (plurarl). And testing 
hanesses go into 'testing'... :)


If you have any further questions, let me know. I'll be happy to help. 
You'll see that Grok is entangled pretty good (I've already managed to 
untangle a lot, but I'm sure there's more).