[Grok-dev] Re: SVN: Sandbox/ulif/grokintrospector/ Create a sandbox
for Grok-related introspector stuff.
Philipp von Weitershausen
philipp at weitershausen.de
Fri Jun 20 14:37:00 EDT 2008
Martijn Faassen wrote:
>> Because I expect some heavy problems during the switch from grok.admin
>> to a separate grokadmin (or megrok.adminui or whatever) package, I
>> *started* it as a real grok.admin extension, to make sure the
>> functionality is available, although there should be major problems with
>> the outfactoring. grok.admin is therefore not the place not the place,
>> the introspector is supposed to be in future.
> I'm not sure whether doing this on two tracks is the best idea. Why not
> focus on getting the separate grokadmin to work first and then starting
> on the grok introspector? This avoids um.. complicated merges. :)
Right. It also helps with code reviews (complicated merges and code
reviews don't go together very well).
>> This way I can track the changes needed to implement introspector
>> functionality and the changes needed to factor out grok.admin from grok
>> better. But that does not seem to be a reasonable thing for others, so I
>> will put that all together tonight and see, how I can differ that
>> changes later on.
> If it's just prototyping I think it's a reasonable approach.
> I do think that an independent grokadmin is hopefully not *that* far
> away, and I was assuming you were going to get that working and then
> would start with the introspector. If you introduce a different skin or
> something, it might even run in parallel with the current built-in admin
> UI so we have less to coordinate and can take out the built-in grok
> admin when we're ready.
>> Anyway, I will make it all grok branches, if that is better traceable by
> Yes, I think sandbox copies of existing projects should be discouraged
> in favor of branches (with externals pointing to them). They're
> technically the same thing, but it's a bit more clear to the project
> what's going on if you do it this way.
Right. I don't think anybody has to be afraid of having his or her work
visible to others. I know I can be a bit harsh when serving as the
"checkin police", but it's all intended to ensure the quality of the
Ben Collins-Sussman (one of the original subversion hackers and head of
the Google Open Source department) recently wrote a very nice article
about why it's important to share your work in communities:
>>> I think we should be focusing on simple light-weight packages that
>>> are developed independently of other packages (such as Grok) as much
>>> as possible.
>>> Note that Grok extensions tend to be called 'megrok.*'. So I'd
>>> suggest megrok.admin and megrok.introspector for the package names.
>> megrok packages, as far as I've seen, are extensions of grok
>> functionality. I got the impression, that they give _developers_ the
>> possibility to do new things. The admin UI will instead become a
>> standalone application (depending on grok, but not really 'extending'
>> it) and giving _end users_ the possibility to do new things. Therefore I
>> thought it would be better placed in `grokapps` or similar places than
>> in megrok. I might be wrong on this as well and will change also that
> There is a difference, indeed. The admin UI itself (without
> introspector) is something a non-developer might want to install,
> possibly, though I'd say it's still mostly a development tool. The
> introspector is definitely a development tool. So in a way it does give
> new features to Grok, though it's not a traditional extension. I do
> think there is a different however.
> We could introduce a 'grokui' namespace for what you're doing. A future
> automatic always-present CRUD UI along the lines of the Django admin UI
> could also be in this namespace (though I hope we'll also see a CRUD
> development framework that allows people to develop custom CRUD UIs.
> Different discussion).
I'm not too keen on introducing yet another namespace. We already have
the top-level package 'grok', and the namespace packages 'megrok' and
While there might be a superficial difference between the admin
interface and, say, RDB integration, it's hard to draw the line where
exactly the "coreness" of a package ends and begins. For instance, when
deploying a Grok app, I might not even need or want the admin interface
installed. After all, it's yet another application written in Grok
that's installed next to my own application. Same goes for the CRUD
I personally think it's absolutely fine to call these things
as they're actual extensions working *on top* of the original Grok
framework. Whether or not they're enabled in a default grokproject
buildout is another question.
Or to rephrase, I'd rather broaden the scope of the 'megrok' namespace
(it's just a namespace, after all) rather than introduce yet another
More information about the Grok-dev