[Grok-dev] Re: paster vs grokproject

[Philipp von Weitershausen]

Tim Terlegård wrote:
> Plone and pylons use paster for creating projects etc. Looks like
> Turbogears 2 will do too. So I think we should too. I briefly looked at
> the source, it looks like grokproject uses paster under the hood?

Yes. grokproject is pretty much a fancy wrapper around 'paster create' 
and zc.buildout (see below).

> Can grokproject do anything paster can?

No, because it just calls 'paster create' internally. paster is so much 
more and in a way so much less: it's just a general script to invoke 
many different commands. I think you're confusing 'paster' with 'paster 
create' in this context...

> What's the advantage of using grokproject instead of paster without
> this wrapper?

So you won't have to do

1. paster create -t grokapp
2. cd MyProj
3. edit buildout.cfg to match current Grok release
4. python bootstrap.py
5. bin/buildout

grokproject basically automates that in one go. Use the source, Luke, 
it's pretty simple and should be documented.

> I think the local command feature of paster can be used to make
> stuff easier for beginners. For instance someone asked on #grok
> where he should put his new app. You need to add stuff to setup.py,
> buildout.cfg and then create these files in src/newapp. It's not
> obvious what to do.

I don't understand the problem. Why couldn't this person have used 
grokproject?

> I would like to do like this:
> 
> $ cd /tmp
> $ paster create -t grokproject MyCoolProject
> $ cd MyCoolProject
> $ paster create app sampleapp
> 
> When creating the sample app it adds what is added today with
> grokproject when you create the new project, but it also adds the
> python package to setup.py, configure.zcml, buildout.cfg or
> whereever it's necessary.

Can you elaborate what you mean by 'app'? Do you want multiple packages 
or multiple eggs within a project? What's the problem with creating 
multiple projects? Can you contrast what you currently have to do to 
achieve whatever you're trying to achieve vs. what you'd like it to look 
like?

> "paster create -t grokproject" could perhaps ask if you want a
> buildout in a virtualenv or just buildout or just virtualenv.
> 
> "paster create devapp" could ask for an svn url and it would then
> check that out in src/, adding it to develop in buildout.cfg and do
> whatever else is necessary to get it picked up when you start zope.

AFAIK, 'paster create' isn't that automatable (e.g. you can't make it 
check out things from SVN). 'paster create' just creates directory 
structures based on templates and user input.

This is the reason why we wrote grokproject in the first place: to do 
more than just the directory structure generation.

> By using paster (and I suspect grokproject does that) I think people
> can add all kinds of local commands. But by calling it 'grokproject'
> you hide what you really can do with the tool. If I'm told to use the
> paster tool to deal with grok I know right away how to get started and
> I know how to use it and that it has "local" capabilities. If the tool is
> called 'grokproject' I will know nothing about it, it's not familiar. It's
> another tool I have to learn.

I suppose we could have implemented grokproject as a paster command, e.g.

   paster grokproject [args]

I'm quite indifferent as to whether that's better or not. Regarding 
"local capabilities," I know that other projects are using custom 
commands to generate more code when they're *within* a project, e.g. (IIRC):

   paster create -t plone3buildout
   cd MyPloneApp
   paster contenttype FooDocument

While this is nice for Plone/Zope3 where writing a content type involves 
a bunch of different things (interface, class, ZCML, CMF registry, 
etc.), I hope that it's easy enough with Grok that we won't need this 
kind of automation. If we needed it, we should think about making Grok 
easier in the relevant places. That's what I think at least, I can 
imagine tool-oriented people will probably disagree.