[Grok-dev] paster vs grokproject

Tim Terlegård tim.terlegard at gmail.com
Mon Jan 28 15:05:39 EST 2008

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?
Can grokproject do anything paster can?

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

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

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

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  
called 'grokproject' I will know nothing about it, it's not familiar.  
another tool I have to learn.

Does this make sense? What advantages does grokproject have
over paster?


More information about the Grok-dev mailing list