[Grok-dev] Grok 1.1 important issues

[Vincent Fretin]

Hi,

FYI, grokproject is just a shortcut to
paster create -t grok
and then it runs bin/boostrap.py and bin/buildout automatically and
download the big tarball.

Sometimes I only want to generate a skeleton, not to download the big
tarball, or add first some packages in the buildout.cfg before running
the buildout.
In this case I don't use grokproject directly.
In ZopeSkel 2.15, it's even simpler with the new zopeskel command:
zopeskel grok

Vincent


On Fri, Feb 26, 2010 at 4:46 AM, Steve Schmechel
<steveschmechel at yahoo.com> wrote:
> 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
>>
>
>
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>