[Grok-dev] Re: SVN: Sandbox/ulif/grokintrospector/ Create a sandbox for Grok-related introspector stuff.

[Philipp von Weitershausen]

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
>> others.
> 
> 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 
software.

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: 
http://blog.red-bean.com/sussman/?p=96.

>>> 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
>> namespacing.
> 
> 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 
'grokcore'.

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 
interface.

I personally think it's absolutely fine to call these things

   megrok.admin
   megrok.autocrud
   megrok.introspector

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 
namespace.