[Grok-dev] Grok 1.1 important issues

[Steve Schmechel]

Could someone please review how grokproject actually benefits Grok?

When I use it, it appears to simply:

1) prompt for a project name
2) prompt for a administrative user name
3) prompt for an administrative password
4) run some sort of easy_install process to get basic files
5) run buildout the first time to get the rest of Grok's dependencies.
6) create a few convenience scripts that are named based on the project
name.

Most of the time, I enter a project name, and "grok", "grok".  I end
up running buildout again fairly shortly after starting my work to
include needed packages.  Before deploying the project, I edit the
necessary files to change the initial login and password.

Could a combination of simple, existing tools and a little different
documentation accomplish the same thing and avoid requiring a separate
external application?

Maybe a paster template could setup the project folders, template
files, and scripts.  Then you would run buildout when appropriate.

For the tutorial, this would be the next step, so that the user could
see the application running right away.  (This seems to be the most
obvious benefit of grokproject.)  

For veteran developers or in tutorials demonstrating a particular
feature, running buildout would happen after they have modified
buildout.cfg and/or setup.py as needed for the particular project.

Admittedly, I have been using repoze.bfg and the have gotten used to
this style of initial project setup.  I don't know if easy_install is
even an option for Grok, but it would be nice if starting a project
for Grok looked like this:

$ bin/easy_install -i http://grok.zope.org/grok/current grok
$ bin/paster create -t grok_starter
  Enter project name: MyProject
$ cd MyProject
$ ../bin/python setup.py develop

Where "grok_starter" is a template that sets up a basic project like
grokproject does.  (Other templates could be provided by the Grok devs
or people could create their own.)

If you want to install a different version, you pick an easy_install
index other than current and provides the set of compatible packages
for that version.

I don't know if any of this is applicable to Grok.  Maybe I am missing
something that grokproject is really useful for.  

It just seems that having to ask things like:

"What version of Grok are you using in your project?" 
  and 
"What version of grokproject did you use to install your project?" 
  and 
"What extra parameters did you use with grokproject when creating your
project?" 

add a lot of extra uncertainty when troubleshooting a new user's
problem, if all it does is make setting up their first project a few
steps shorter.

Steve

--- On Thu, 2/25/10, Jan-Wijbrand Kolman <janwijbrand at gmail.com> wrote:

> From: Jan-Wijbrand Kolman <janwijbrand at gmail.com>
> Subject: Re: [Grok-dev] Grok 1.1 important issues
> To: grok-dev at zope.org
> Date: Thursday, February 25, 2010, 1:10 PM
> Jan-Wijbrand Kolman <janwijbrand at gmail.com>
> wrote:
> > Important remark:
> > 
> > The grokproject tool download the
> releaseinfo/grok-1.1rc1.cfg file into the 
> > newly created project as a versions.cfg file to
> support offline building.
> > 
> > The grok.cfg in the groktoolkit extends the ztk.cfg in
> the zopetoolkit and if 
> > we upload it to releaseinfo/grok-1.1rc.cfg without
> modifications, we will 
> > break the offline building possbility, since the
> downloaded file will still
> > extend the ztk.cfg file.
> > 
> > In other words, I think the grok.cfg file in a
> groktoolkit _release_ needs to 
> > include the versions of the zopetoolkit and not extend
> the ztk.cfg.
> > 
> > This will be a extra step in the release proces. When
> doing the release I'll 
> > change the release notes accordingly.
> 
> I wonder now:
> 
> Couldn't grokproject depend on zc.buildout itself?
> 
> This would (maybe) solve two things:
> 
> 1) Simplify the ugly dance in grokproject.util where
> buildout functionality is 
> invoked as well.
> 
> 2) We could maybe make use of buildout functionality in
> grokproject to retrieve 
> the version requirements as buildout can, obviously,
> recurse through the extends 
> directives. We would then not have to flatten zopetoolkit's
> ztk.cfg and 
> zopeapp.cfg and groktoolkit's grok.cfg version parts into
> one file...
> 
> regards,
> jw
> 
> 
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>