[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
Hey,
Brandon Craig Rhodes wrote:
[snip]
> 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
mechanisms.
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.
Regards,
Martijn
More information about the Grok-dev
mailing list