[Grok-dev] Grok sprint for PyCon 2008: grokcore
Brandon Craig Rhodes
brandon at rhodesmill.org
Fri Mar 14 13:06:52 EDT 2008
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"
(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".
(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.
(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.
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
I hope to see several of you there! I'll tout the Sprint at the end
of my talk, since it relates directly to my talk's conclusion - my
talk sets up the sprint topic as the logical next step for Grok's
Brandon Craig Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon
More information about the Grok-dev