[Grok-dev] Grok 1.1 important issues

[Steve Schmechel]

I forgot about downloading and unpacking the tarball.

Is it possible that, with all the "dependency trimming" 
going on with Grok, the need for the tarball might begin 
to diminish also?  (In other words, all GTK and ZTK packages 
are properly deployed on PyPI and download times not 
significantly longer that with the tarball.)

Having the tarball is nice but, if Grok were to make 
releases more frequently, wouldn't having a good egg cache
be more efficient than downloading a new tarball each time?

I'm not saying that something needs to be done right away.
It just seems prudent to remember *why* these "extras" were
added and occasionally reevaluate their benefit.

I might be wrong, but it appears that grokproject was an 
attempt to make it as "easy as Rails" to demonstrate Grok
in "20 minutes" or "10" or "5" or whatever.

The tarball was in response to unreliability of accessing 
various package stores outside of PyPI.  (If PyPI is down, 
you are likely out of luck even if you find another way to 
get the Grok tarball.)

I just worry that these "extras" will become so entrenched 
in the documentation that they will have to be preserved 
even if the initial reason for implementing them no longer
exists.

Maybe no one else shares this concern.  That's OK also.


Steve 

--- On Fri, 2/26/10, Vincent Fretin <vincent.fretin at gmail.com> wrote:

> From: Vincent Fretin <vincent.fretin at gmail.com>
> Subject: Re: [Grok-dev] Grok 1.1 important issues
> To: "Steve Schmechel" <steveschmechel at yahoo.com>
> Cc: grok-dev at zope.org, "Jan-Wijbrand Kolman" <janwijbrand at gmail.com>
> Date: Friday, February 26, 2010, 2:23 AM
> 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
> >
>