[Grok-dev] Re: Grok sprint for PyCon 2008: grokcore
Philipp von Weitershausen
philipp at weitershausen.de
Sat Mar 15 08:23:54 EDT 2008
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
> (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
* 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
* 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
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).
More information about the Grok-dev