grokproject 1.0a1

Script that sets up a grok project directory, installs Zope 3 and grok and creates a template for a grok application.

grokproject provides an easy way to get started with a Grok web application. Simply install grokproject:

$ easy_install grokproject

and run the grokproject script with the name of the project you’d like to create as an argument:

$ grokproject MammothHerd
... many lines of output here

This will not only create a project area for you to work in, it will also download and install Grok and Zope 3 (the application server Grok is built on).

After the project area has been created successfully, you will find an empty Python package in the src directory in which you can place the code for your web application.

To start the application server, execute:

$ cd MammothHerd
$ bin/paster serve etc/deploy.ini

There is also an Ajax enabled debugger (point your browser to http://localhost:8080/@@login.html when using this):

$ bin/paster serve etc/debug.ini

Start/stop it in daemon mode:

$ bin/mammothherd-ctl start
$ bin/mammothherd-ctl stop

Start the debugger:

$ bin/mammothherd-debug

For those who know paster: grokproject is just a wrapper around a paster template. So instead of running the grokproject command, you can also run:

$ paster create -t grok MammotHerd

To create a project with the previous zopectl layout run the grokproject script like:

$ grokproject --zopectl MammothHerd

or:

$ paster create -t grok MammothHerd zopectl=True

Changes

1.0a1 (2009-01-08)

• Fixed bug: using the --svn-repository option would fail with an OSError.

• Add another template set for paster support

• Add option –zopectl to select ‘zopectl’ templates

• Make ‘paster’ the default template set

0.9 (2008-09-29)

• Add grokui.admin as a dependency for projects created with grokproject.

• Respect the verboseness requested by the user when running the final install.

• Fix behaviour that produced double/triple output when buildout was invoked several times.

• grokproject now uses z3c.recipe.i18n instead of lovely.recipe for generation of i18n-scripts.

• At the end of the bootstrap.py of the generated project we now give the user a hint that he can run bin/buildout.

• Explicitly run the install of the eggbasket recipe.

• Fix ftesting.zcml to not include grok package : it precludes overrides of anything included by grok.

0.8 (2008-07-14)

• Pinned zc.buildout and the used recipes in the generated versions.cfg.

• Check for download errors when getting the release info files from grok.zope.org. That way we give a meaningful error message to the user.

• Removed dependency on zc.buildout as we already use bootstrap.py-like code to install it on the fly if it is not there yet.

• Removed code that was factored out into z3c.recipe.eggbasket and already gets invoked by grokproject by doing a “buildout bootstrap”.

• Actually added the required eggbasket section to the generated buildout.cfg. Fixes https://bugs.launchpad.net/grok/+bug/242368

• Catch download error when trying to get the big grok tarball.

• Use a hardcoded bootstrap.py instead of referring to it via an external or downloading the current trunk revision upon each grokproject run (those options are potentially dangerous).

  Also added a line at the end of bootstrap.py to install the eggbasket section.

• Added a testbrowser test / functional test to the template.

• Added a dependency on z3c.testsetup for created projects.

• Factor out functions is_grok_installed and install_grok.

• When grok is not installed yet, download a tar ball with all eggs needed by Grok and install those in the shared eggs directory.

• If the user has a ~/.buildout/default.cfg nothing is added to the created buildout.cfg. If there is no default.cfg one is created with a line specifying the eggs-directory to ~/.buildout/eggs. If the user specified –eggs-dir/eggs_dir on the command line that will be added to buildout.cfg.

• When there is no .buildout/default.cfg file, create it. Only put eggs-directory in the created buildout.cfg file when the user does not have it in default.cfg yet.

• Do not ask for eggs dir when we have a default already.

• Refactor grokproject/__init__.py by moving things out into main.py, templates.py and utils.py, like zopeproject does.

• Add README.txt file to the created static/ dir. Biggest reason: otherwise ‘python setup.py sdist’ simply does not add that empty directory.

• Added local download of the current fixed versions as versions.cfg.

• Add handling for the eggs-directory option in buildout.cfg, taken from zopeproject.

• Added a test for grokproject itself.

• Copy the run_buildout function from zopeproject and put it in utils.py. Call that in the post hook of our paste template. In the grokproject command after calling paster just quit.

• Do checks before asking questions. Define getters for some vars. Move no_buildout from the command to run_buildout in the template. Use version_info_url in the template instead of renaming it to extends.

• Remove the –newer option for bin/grokproject. Use the ‘newest’ option from the template instead.

• Move version_info_url to the template vars without making it a real question.

• Rename the grokproject template to just grok. ME GROK LIKE SHORT NAMES.

• Do not add eggs-directory to the buildout.cfg, as the absolute paths created make the resulting project unusable on other computers.

• “bin/paster create -t grokproject” now works again.

• Make sure bin/paster gets added so we can also test only our paster template instead of the command.

• Fix https://bugs.launchpad.net/grok/+bug/223247: grokproject generates faulty ftesting.zcml. Replaced zope.app.securitypolicy.zopepolicy.ZopeSecurityPolicy with zope.securitypolicy.zopepolicy.ZopeSecurityPolicy in ftesting.zcml template (Depends on a Grok release > 0.11.1).

0.7 (2008-04-22)

• Each of the interactive questions can now be set with an commandline option.

• No longer ask for the name of the module that will contain the grok.Application subclass. It’s ‘app.py’ by default now, a rename is easy enough to do later on.

• Fix https://bugs.launchpad.net/bugs/161947: The buildout.cfg template contained the [data] section twice.

• Generate <includeDependencies package="." /> statement by default. If new dependencies are added to setup.py that need ZCML, the ZCML will be automatically loaded. (Depends on a new release of Grok with z3c.autoinclude)

0.6 (2007-10-10)

• Added include package directive to ftesting.zcml_tmpl to enable functional testing of the generated application.

• Updated template for site.zcml, no annoying warning at start.

• Added buildout support for i18n (thanks to lovely.recipe.i18n).

• The buildout.cfg that is created now has an extends directive that points to URL of the version.cfg of the current Grok release. This URL can be overridden with the –version-info-url commandline option.

  See http://grok.zope.org/releaseinfo/readme.html for more information.

0.5.1 (2007-07-14)

• Use the new ‘application’ recipe from zc.zope3recipes so that we can get rid of the dead chicken [zope3] section in buildout.cfg.

0.5 (2007-07-14)

• The bin/instance script has been renamed to bin/zopectl for better recognizability.

• grokproject is much quieter by default (by quieting down PasteScript, easy_install and zc.buildout). Use the -v option for verbose mode.

• Fixed https://bugs.launchpad.net/grok/+bug/119805: A new project created with grokproject can’t be called ‘grok’ or ‘zope’.

• By default, zc.buildout will now be told to place eggs in a user-specified shared eggs directory. Also, it will not look for newer versions of existing eggs by default.

0.4 (2007-07-12)

• As grok now depends on Zope 3.4 eggs, use zc.zope3recipes application and instance recipes.

• Don’t spawn processes to bootstrap and run the buildout. Instead, try to simply import zc.buildout. If that doesn’t work, call the setuptools API to install it and then simply import it.

• Fixed https://bugs.launchpad.net/grok/+bug/113103: Default index template was missing closing html tag.

0.1 thru 0.3

Initial development versions, supporting Zope 3.3.