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

Martijn Faassen faassen at startifact.com
Sat Jun 21 08:14:08 EDT 2008


Brandon Craig Rhodes wrote:
> Are we imagining, therefore, that sometime in the near future a
> newly-created "grokproject" might list several dependencies - say, both
> 'grok' and 'megrok.admin'? - and that by taking some of them out a Grok
> user could opt out of features that we want available by default for
> people getting started with Grok?
> That would be great.

We want something like this, though we're not sure yet about the precise 

I'd say this is a distinction between the megrok.* and grokui.* 
namespaces. I think we'll see a way to get particular grokui.* bits 
installed or not installed, but we'll never see this with megrok; which 
megrok to include or not is up to the developer who needs the functionality.

With grokui you could have a production profile which doesn't include 
grokui.admin (or only a minimal version), and a development profile 
which does.

The mechanisms are a bit unclear as of yet. I don't think should list 
grokui.admin as a dependency in the setup.py of something generated by 
grokproject, as that means that you'd need to keep adding and removing 
it depending on whether you're releasing for deployment or going to 
development. Perhaps we can do it so we add it as a development buildout 
dependency, and then have a bit of ZCML that loads up this dependency, 
and then have a different buildout for production which doesn't do this.

For now however (0.14), we'll make Grok core rely on grokui.admin, as we 
just want to move forward step by step and not wait until all of this is 
worked out. Separating it out of the core is the first step.



More information about the Grok-dev mailing list