[Checkins] SVN: grokproject/trunk/ Moved to GitHub.
Stephen Richter
cvs-admin at zope.org
Fri Mar 1 15:43:12 UTC 2013
Log message for revision 129959:
Moved to GitHub.
Changed:
D grokproject/trunk/CHANGES.txt
D grokproject/trunk/COPYRIGHT.txt
D grokproject/trunk/LICENSE.txt
A grokproject/trunk/MOVED_TO_GITHUB
D grokproject/trunk/README-shorttests.txt
D grokproject/trunk/README.txt
D grokproject/trunk/TODO.txt
D grokproject/trunk/bootstrap.py
D grokproject/trunk/buildout.cfg
D grokproject/trunk/grokproject/
D grokproject/trunk/setup.py
D grokproject/trunk/tests.py
D grokproject/trunk/tests.txt
D grokproject/trunk/upgrading.txt
-=-
Deleted: grokproject/trunk/CHANGES.txt
===================================================================
--- grokproject/trunk/CHANGES.txt 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/CHANGES.txt 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,551 +0,0 @@
-Changes
-=======
-
-2.10 (unreleased)
------------------
-
-- Nothing changed yet.
-
-
-2.9 (2013-02-14)
-----------------
-
-- Fix the brown-paper-bag 2.8 release where not all files necessary for the
- source distribution were included.
-
-2.8 (2013-02-13)
-----------------
-
-- Update bootstrap.py (for both the grokproject buildout *and* the project
- template) to use zc.buildout <2.0dev.
-
-2.7 (2012-05-02)
-----------------
-
-- Include grokcore.chameleon. Have the generated index view template be
- a chameleon based template.
-
-2.6 (2011-05-26)
-----------------
-
-- There was an inconsistency where the various logfiles we placed. Fixed the
- situation by using the intended "{buildout}/var/log" location throughout.
-
-- Remove the ``log`` and ``data`` part stubs that were left for backwards
- compatibility. Deprecation period is over. NOTE: if you are to update an
- existing project by replacing your ``buildout.cfg`` with that of a newly
- generated project, please make sure there is no important data ``data`` and
- ``log`` subdirectories left!
-
-2.5 (2011-02-02)
-----------------
-
-- Better checks and tests for faulty project names.
-
-2.4 (2011-01-20)
-----------------
-
-- z3c.testsetup has been removed in favor of manual registration of tests.
- Tests have been moved to 'tests' subdirectory.
- See tests.py for more information on how to register tests.
-
-- The 'static' directory is no longer grokked and registered as a
- DirectoryResource. It has been superseded by `fanstatic`_.
-
- In order to update your current grok project to the most recent grokproject,
- you need to register a fanstatic Library for the `static` directory.
-
- Include the following code in ``resource.py``::
-
- from fanstatic import Library
- library = Library('$name_of_your_project', 'static')
-
- in the setup.py of your project, add the following entry point::
-
- 'fanstatic.libraries': [
- '$name_of_your_project = $name_of_your_project.resource:library',
- ]
-
- Also add `zope.fanstatic` and `fanstatic` to `install_requires` in your
- setup.py. If you are using z3c.autoinclude in your configure.zcml, the
- registrations of zope.fanstatic will be picked up automatically. If you
- do not use z3c.autoinclude, include zope.fanstatic in your configure.zcml.
-
-- Split up zope.conf into zope.debug.conf and zope.deploy.conf, in order to
- pick these up from the paster configs debug.ini and deploy.ini.
-
- In debug/devmode, grok picks up changes in page templates and fanstatic
- recalculates resources URLs.
-
- In non-dev/deploy mode grok caches page templates and fanstatic caches
- resource URLs.
-
- The goal is to quickly see the difference between debug.ini and deploy.ini
- without having to mess around in parts/etc.
-
-.. _`fanstatic`: http://fanstatic.org
-
-2.3 (2011-01-10)
-----------------
-
-- Use 'extensions +=' instead of 'extensions =' to be able to define extensions
- in other cfg files we extend.
-
-- Added include_site_packages, install_requires, and additional_grants
- variables in the template for use in dolmenproject.
- Use vars and template_main parameters in main function so it can be reused
- in dolmenproject.
-
-2.2.1 (2011-01-05)
-------------------
-
-- The accesslogging filter in deploy.ini was lost and refound.
-
-2.2 (2010-11-26)
-----------------
-
-- `unzip=true` default behavior in buildout.cfg.
-
-- Added 'daemon' part to the newly created buildout.cfg.
-
-- Work around '-S' bug in virtualenv.
- https://bugs.launchpad.net/virtualenv/+bug/572545
-
-2.1 (2010-10-26)
-----------------
-
-- **NOTE: As a result of these changes, ``grokproject`` will no longer
- support building projects based on Grok versions earlier than 1.2!**
-
-- Removed the ``--grokversion`` and ``--grok-release-url`` commandline
- options, in favor of the ``-version-url`` option. This URL should point to a
- buildout ``*.cfg`` file containing version "pins" for all the packages
- involved. The default URL is still looked up by way of
- http://grok.zope.org/releaseinfo/current.
-
-- The newly created project will use the test layer and test browser from
- ``zope.app.wsgi.testlayer``.
-
-- Delegate bootstrapping a newly created project to the project's
- ``bootstrap.py`` and the project's ``bin/buildout``. This isolates the
- bootstrapping from grokproject itself and prevents potential zc.buildout
- version conflicts.
-
-- Update to use z3c.recipe.scripts instead of zc.recipe.egg as part of the
- upgrade to zc.buildout-1.5.2.
-
-2.0.1 (2010-05-30)
-------------------
-
-- Make sure the otherwise empty log and extends-cache directories exist.
-
-2.0 (2010-05-30)
-----------------
-
-* Use a pipeline for setting up the application.
-
-* Add logger ``grok`` in ``debug.ini`` and ``deploy.ini``
- templates. This logger logs warning messages emitted by more recent
- versions of grokcore.view template registry (and has no effect
- with older grok versions).
-
- By default warning messages are displayed in ``debug.ini`` and
- disabled in ``deploy.ini``.
-
- To change settings, edit section ``[logger_grok]`` in
- ``etc/debug.ini.in`` and ``etc/deploy.ini.in`` respectively and
- rerun buildout afterwards.
-
-* Use a new "version information" layout on http://grok.zope.org/releaseinfo.
-
- More specifically, the "bundlemaker" or "eggbasket" feature is no longer
- used. Instead, grokproject expexts to find a
- http://grok.zope.org/releaseinfo/[y.x]/versions.cfg file and a
- http://grok.zope.org/releaseinfo/[y.x]/eggs directory containing
- distributions for all the dependencies of grok.
-
- This "eggs" directory is used by way of the ``find-links`` directive in the
- ``buildout.cfg`` of newly created projects.
-
- The ``versions.cfg`` file extends the groktoolkit files that in turn extend
- from the zopetoolkit cfg files. The newly created project will have an
- ``extends-cache`` directive set, in order to support "off-line" building (as
- long as no new packages are required for building).
-
- **NOTE: As a result of these structural changes, ``grokproject`` will no
- longer support building projects based on Grok versions earlier than 1.1.1
- (or earlier than 1.0.2, for the 1.0-line of Grok releases).**
-
-* Remove the interactive debugger entry point in favor of a buildout part
- that generates a similar commandline tool for the newly created project.
-
-* Use the zpassword functionality for the bin/zpasswd tool.
-
-* No longer build the zdaemon ctl.
-
-* Projects created will use the #main and #debug entry points now defined
- in grokcore.startup.
-
-* The application specific version pins are now in Grok's versions cfg.
-
-* Remove '--zopectl' option. Paster setups are now the only supported
- method to create new projects.
- Fix bug https://bugs.launchpad.net/grok/+bug/524262
-
-1.0.3 (2010-02-21)
-------------------
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/524000
- Firsttime-user problem on win32: grokproject didn't work if no
- .buildout/default.cfg existed and user had no pywin32 already installed.
-
-* Pin zope.app.container 3.8.1 and zope.app.folder 3.5.1 for project
- created with Grok 1.1a2 KGS (those packages were not pinned in the released
- versions.cfg).
-
-* For Python 2.5 and 2.6, use hashlib module instead of the deprecated
- sha module in Python 2.6.
-
-* Use bugfixed grokui.admin 0.4.1.
-
-1.0.2 (2010-02-14)
-------------------
-
-* Added license file.
-
-1.0.1 (2010-01-24)
-------------------
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/487561 Granted
- ``zope.View`` and ``zope.app.dublincore.view`` permissions for all
- users (also authenticated ones) in site.zcml and ftesting.zcml
- templates.
-
-* Pinned down zc.zope3recipes for zopectl-driven installs. The more
- recent versions of zc.zope3recipes require zc.recipe.egg >= 1.2.0
- which we currently do not support. As a result zctl-builds could
- fail due to unmet version constraints.
-
-
-1.0 (2009-10-07)
-----------------
-
-* The ``debug.ini`` file now by default configures the Unuathorized
- exception to not to be reraised. This will make sure Zope's authentication
- mechanism keep working when using the ``z3c.evalexception`` middleware.
-
-
-1.0b1 (2009-09-17)
-------------------
-
-* The var/ directory is now used for var/filestorage, var/blobstorage and
- var/log instead of storing all that in the parts/ directory. This matches
- expectations of most users: parts/ can be rebuild, var/ must be backed up.
-
-* Added blob-storage in paster template's `zope.conf.in`. Blob-storage
- is enabled by default.
-
-* Removed ``find-links`` from `buildout.cfg`.
-
-* Added two packages to the pinned versions in generated projects:
- z3c.recipe.dev = 0.5.3
- zc.lockfile = 1.0.0
-
-* Using the just released z3c.recipe.eggbasket 0.4.3 in the generated
- projects.
-
-* Increased z3c.recipe.i18n version to use: 0.5.3 does not emit any
- warnings any more when being installed.
-
-* Assert that project names are valid python identifiers
- https://bugs.launchpad.net/bugs/223560
- https://bugs.launchpad.net/bugs/373592
-
-* Generate the site.zcml containing the new default permission for grok.
- grok.View is now the default view instead of zope.Public.
-
- https://bugs.launchpad.net/bugs/387332
-
-
-1.0a4 (2009-04-17)
-------------------
-
-* Fixed wrong site-definition path in generated zope.conf.
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/358719
- Backslashes in Windows paths are now quoted in Python expressions in
- configuration .ini files. Patches, testing and solutions from Ben
- Dadsetan and Roger Erens.
-
-* Add filter to include only eggs in generated versions.cfg that are
- not already provided by a downloaded grok KGS.
-
-* Reintroduce ``find-links`` to Zope package index in generated
- buildout.cfg to avoid problems with z3c.widget and other packages
- needing packages only hosted on Zope.
-
-* Removed `grokui.admin` from generated versions.cfg. It should be
- pinned down by Groks versions.cfg.
-
-
-1.0a3 (2009-04-03)
-------------------
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/315223
- The eggs-directory path that we put in ~/.buildout/default.cfg is
- now a shortened version on Windows (8.3 DOS style).
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/160196 The initial
- password is now stored SHA1 encoded.
-
-* Make the `zope.app.server.zpasswd` utility available as a
- commandline tool in bin/.
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/325299 The config files
- in paster-based grok projects are now generated by ``zc.buildout``
- in the new location ``parts/etc/`` and can be adjusted to local
- environments. Rerunning ``bin/buildout`` now rebuilds the
- configuration files in ``parts/etc/`` from the templates that can be
- found in ``etc/``.
-
- To start paster you now have to do::
-
- $ bin/paster serve parts/etc/deploy.ini
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/315214 by supporting
- faster test runs. See README-shorttests.txt for details.
-
-* Pinned all package versions in the generated versions.cfg to the
- latest released ones. Especially pinned z3c.recipe.eggbasket to
- the most recent one, 0.4.1.
-
-* Integrated with grokcore.startup
- Removed ``startup.py`` from the paster template
-
-* Paster: you need to first access http://localhost:8080/@@login.html
- when running the debug.ini profile
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/332173
- add middleware to support access logging
-
-1.0a2 (2009-01-12)
-------------------
-
-* Add option ``--grokversion`` which installs the requested version of
- Grok with the created project. Examples::
-
- grokproject --grokversion=0.14.1 Sample
-
- or::
-
- paster create -t grok Sample grokversion=0.14.1
-
-* Add option ``--version`` to show grokproject version and stay
- compatible with most command-line tools.
-
-* Fix bug https://bugs.launchpad.net/grok/+bug/315795 paster variant
- of grokproject now again accepts projectnames with uppercase chars.
-
-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.
Deleted: grokproject/trunk/COPYRIGHT.txt
===================================================================
--- grokproject/trunk/COPYRIGHT.txt 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/COPYRIGHT.txt 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1 +0,0 @@
-Zope Foundation and Contributors
\ No newline at end of file
Deleted: grokproject/trunk/LICENSE.txt
===================================================================
--- grokproject/trunk/LICENSE.txt 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/LICENSE.txt 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,44 +0,0 @@
-Zope Public License (ZPL) Version 2.1
-
-A copyright notice accompanies this license document that identifies the
-copyright holders.
-
-This license has been certified as open source. It has also been designated as
-GPL compatible by the Free Software Foundation (FSF).
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are met:
-
-1. Redistributions in source code must retain the accompanying copyright
-notice, this list of conditions, and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the accompanying copyright
-notice, this list of conditions, and the following disclaimer in the
-documentation and/or other materials provided with the distribution.
-
-3. Names of the copyright holders must not be used to endorse or promote
-products derived from this software without prior written permission from the
-copyright holders.
-
-4. The right to distribute this software or to use it for any purpose does not
-give you the right to use Servicemarks (sm) or Trademarks (tm) of the
-copyright
-holders. Use of them is covered by separate agreement with the copyright
-holders.
-
-5. If any files are modified, you must cause the modified files to carry
-prominent notices stating that you changed the files and the date of any
-change.
-
-Disclaimer
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY EXPRESSED
-OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
-EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY DIRECT, INDIRECT,
-INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
-PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
-LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
-NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
-EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Added: grokproject/trunk/MOVED_TO_GITHUB
===================================================================
--- grokproject/trunk/MOVED_TO_GITHUB (rev 0)
+++ grokproject/trunk/MOVED_TO_GITHUB 2013-03-01 15:43:12 UTC (rev 129959)
@@ -0,0 +1 @@
+See https://github.com/zopefoundation/grokproject
\ No newline at end of file
Deleted: grokproject/trunk/README-shorttests.txt
===================================================================
--- grokproject/trunk/README-shorttests.txt 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/README-shorttests.txt 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,28 +0,0 @@
-Shortening test runs
-********************
-
-By default testruns of `grokproject` take a huge amount of time.
-
-This is primarily caused by eggs, which are downloaded and installed
-in freshly created eggs directories during test runs. A complete set
-of eggs is downloaded and installed at least two times during each
-run.
-
-Most time is taken by compiling and installing all the eggs.
-
-We can reduce this large amount of time by skipping recreation of
-eggs-directories between single tests and between test runs.
-
-This can be forced by creating a file 'shorttests' in this directory,
-which, if it exists, cares for leaving an existing eggs dir
-untouched. You can create such a file like this::
-
- $ touch shorttests
-
-Note, that the first run, however, will take much time but subsequent
-runs will be much shorter (by factor 10 or more).
-
-Before submitting to the repository you might want to run the 'full'
-tests again, which can be done by removing the marker file::
-
- $ rm shorttests
Deleted: grokproject/trunk/README.txt
===================================================================
--- grokproject/trunk/README.txt 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/README.txt 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,64 +0,0 @@
-grokproject provides an easy way to get started with a `Grok
-<http://pypi.python.org/pypi/grok>`_ web application. Simply
-install ``grokproject``::
-
- $ easy_install grokproject
-
-If you have an old version of grokproject installed then you can
-upgrade doing::
-
- $ easy_install -U grokproject
-
-Afterwards you can 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 its dependencies.
-
-After the project area has been created successfully, you will find an empty
-Python package "skeleton" 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 parts/etc/deploy.ini
-
-Start/stop it in daemon mode::
-
- $ bin/daemon start/stop
-
-There is also an Ajax enabled debugger (point your browser to
-http://localhost:8080/@@login.html when using this)::
-
- $ bin/paster serve parts/etc/debug.ini
-
-To start the interactive debugger prompt::
-
- $ bin/interactive_debugger
-
-To run an ad-hoc Python script against a full setup application::
-
- $ bin/interactive_debugger [name_of_python_script].py
-
-Python scripts run this way, will have access to a ``root``, ``debugger``, and
-an ``app`` object avaible for "interacting" with the application environment.
-
-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
-
-All configuration files used for running Grok can be found in the
-``parts/etc/`` directory of your project. These configuration files are
-generated automatically from the templates in ``etc/`` on each ``buildout``
-run. To modify the configuration files edit the approriate templates in
-``etc/`` and rerun ``buildout`` afterwards::
-
- $ bin/buildout
-
-This will rebuild the files in ``parts/etc/``.
Deleted: grokproject/trunk/TODO.txt
===================================================================
--- grokproject/trunk/TODO.txt 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/TODO.txt 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,7 +0,0 @@
-* Allow creating projects with dotted names.
- See https://bugs.launchpad.net/grok/+bug/223560
-
-* Make a template for megrok.something
-
-* Make tests run under Windows
-
Deleted: grokproject/trunk/bootstrap.py
===================================================================
--- grokproject/trunk/bootstrap.py 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/bootstrap.py 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,277 +0,0 @@
-##############################################################################
-#
-# Copyright (c) 2006 Zope Foundation and Contributors.
-# All Rights Reserved.
-#
-# This software is subject to the provisions of the Zope Public License,
-# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
-# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
-# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
-# FOR A PARTICULAR PURPOSE.
-#
-##############################################################################
-"""Bootstrap a buildout-based project
-
-Simply run this script in a directory containing a buildout.cfg.
-The script accepts buildout command-line options, so you can
-use the -c option to specify an alternate configuration file.
-"""
-
-import os, shutil, sys, tempfile, urllib, urllib2, subprocess
-from optparse import OptionParser
-
-if sys.platform == 'win32':
- def quote(c):
- if ' ' in c:
- return '"%s"' % c # work around spawn lamosity on windows
- else:
- return c
-else:
- quote = str
-
-# See zc.buildout.easy_install._has_broken_dash_S for motivation and comments.
-stdout, stderr = subprocess.Popen(
- [sys.executable, '-Sc',
- 'try:\n'
- ' import ConfigParser\n'
- 'except ImportError:\n'
- ' print 1\n'
- 'else:\n'
- ' print 0\n'],
- stdout=subprocess.PIPE, stderr=subprocess.PIPE).communicate()
-has_broken_dash_S = bool(int(stdout.strip()))
-
-# In order to be more robust in the face of system Pythons, we want to
-# run without site-packages loaded. This is somewhat tricky, in
-# particular because Python 2.6's distutils imports site, so starting
-# with the -S flag is not sufficient. However, we'll start with that:
-if not has_broken_dash_S and 'site' in sys.modules:
- # We will restart with python -S.
- args = sys.argv[:]
- args[0:0] = [sys.executable, '-S']
- args = map(quote, args)
- os.execv(sys.executable, args)
-# Now we are running with -S. We'll get the clean sys.path, import site
-# because distutils will do it later, and then reset the path and clean
-# out any namespace packages from site-packages that might have been
-# loaded by .pth files.
-clean_path = sys.path[:]
-import site # imported because of its side effects
-sys.path[:] = clean_path
-for k, v in sys.modules.items():
- if k in ('setuptools', 'pkg_resources') or (
- hasattr(v, '__path__') and
- len(v.__path__) == 1 and
- not os.path.exists(os.path.join(v.__path__[0], '__init__.py'))):
- # This is a namespace package. Remove it.
- sys.modules.pop(k)
-
-is_jython = sys.platform.startswith('java')
-
-setuptools_source = 'http://peak.telecommunity.com/dist/ez_setup.py'
-distribute_source = 'http://python-distribute.org/distribute_setup.py'
-
-
-# parsing arguments
-def normalize_to_url(option, opt_str, value, parser):
- if value:
- if '://' not in value: # It doesn't smell like a URL.
- value = 'file://%s' % (
- urllib.pathname2url(
- os.path.abspath(os.path.expanduser(value))),)
- if opt_str == '--download-base' and not value.endswith('/'):
- # Download base needs a trailing slash to make the world happy.
- value += '/'
- else:
- value = None
- name = opt_str[2:].replace('-', '_')
- setattr(parser.values, name, value)
-
-usage = '''\
-[DESIRED PYTHON FOR BUILDOUT] bootstrap.py [options]
-
-Bootstraps a buildout-based project.
-
-Simply run this script in a directory containing a buildout.cfg, using the
-Python that you want bin/buildout to use.
-
-Note that by using --setup-source and --download-base to point to
-local resources, you can keep this script from going over the network.
-'''
-
-parser = OptionParser(usage=usage)
-parser.add_option("-v", "--version", dest="version",
- help="use a specific zc.buildout version")
-parser.add_option("-d", "--distribute",
- action="store_true", dest="use_distribute", default=False,
- help="Use Distribute rather than Setuptools.")
-parser.add_option("--setup-source", action="callback", dest="setup_source",
- callback=normalize_to_url, nargs=1, type="string",
- help=("Specify a URL or file location for the setup file. "
- "If you use Setuptools, this will default to " +
- setuptools_source + "; if you use Distribute, this "
- "will default to " + distribute_source + "."))
-parser.add_option("--download-base", action="callback", dest="download_base",
- callback=normalize_to_url, nargs=1, type="string",
- help=("Specify a URL or directory for downloading "
- "zc.buildout and either Setuptools or Distribute. "
- "Defaults to PyPI."))
-parser.add_option("--eggs",
- help=("Specify a directory for storing eggs. Defaults to "
- "a temporary directory that is deleted when the "
- "bootstrap script completes."))
-parser.add_option("-t", "--accept-buildout-test-releases",
- dest='accept_buildout_test_releases',
- action="store_true", default=False,
- help=("Normally, if you do not specify a --version, the "
- "bootstrap script and buildout gets the newest "
- "*final* versions of zc.buildout and its recipes and "
- "extensions for you. If you use this flag, "
- "bootstrap and buildout will get the newest releases "
- "even if they are alphas or betas."))
-parser.add_option("-c", None, action="store", dest="config_file",
- help=("Specify the path to the buildout configuration "
- "file to be used."))
-
-options, args = parser.parse_args()
-
-if options.eggs:
- eggs_dir = os.path.abspath(os.path.expanduser(options.eggs))
-else:
- eggs_dir = tempfile.mkdtemp()
-
-if options.setup_source is None:
- if options.use_distribute:
- options.setup_source = distribute_source
- else:
- options.setup_source = setuptools_source
-
-if options.accept_buildout_test_releases:
- args.insert(0, 'buildout:accept-buildout-test-releases=true')
-
-try:
- import pkg_resources
- import setuptools # A flag. Sometimes pkg_resources is installed alone.
- if not hasattr(pkg_resources, '_distribute'):
- raise ImportError
-except ImportError:
- ez_code = urllib2.urlopen(
- options.setup_source).read().replace('\r\n', '\n')
- ez = {}
- exec ez_code in ez
- setup_args = dict(to_dir=eggs_dir, download_delay=0)
- if options.download_base:
- setup_args['download_base'] = options.download_base
- if options.use_distribute:
- setup_args['no_fake'] = True
- if sys.version_info[:2] == (2, 4):
- setup_args['version'] = '0.6.32'
- ez['use_setuptools'](**setup_args)
- if 'pkg_resources' in sys.modules:
- reload(sys.modules['pkg_resources'])
- import pkg_resources
- # This does not (always?) update the default working set. We will
- # do it.
- for path in sys.path:
- if path not in pkg_resources.working_set.entries:
- pkg_resources.working_set.add_entry(path)
-
-cmd = [quote(sys.executable),
- '-c',
- quote('from setuptools.command.easy_install import main; main()'),
- '-mqNxd',
- quote(eggs_dir)]
-
-if not has_broken_dash_S:
- cmd.insert(1, '-S')
-
-find_links = options.download_base
-if not find_links:
- find_links = os.environ.get('bootstrap-testing-find-links')
-if not find_links and options.accept_buildout_test_releases:
- find_links = 'http://downloads.buildout.org/'
-if find_links:
- cmd.extend(['-f', quote(find_links)])
-
-if options.use_distribute:
- setup_requirement = 'distribute'
-else:
- setup_requirement = 'setuptools'
-ws = pkg_resources.working_set
-setup_requirement_path = ws.find(
- pkg_resources.Requirement.parse(setup_requirement)).location
-env = dict(
- os.environ,
- PYTHONPATH=setup_requirement_path)
-
-requirement = 'zc.buildout'
-version = options.version
-if version is None and not options.accept_buildout_test_releases:
- # Figure out the most recent final version of zc.buildout.
- import setuptools.package_index
- _final_parts = '*final-', '*final'
-
- def _final_version(parsed_version):
- for part in parsed_version:
- if (part[:1] == '*') and (part not in _final_parts):
- return False
- return True
- index = setuptools.package_index.PackageIndex(
- search_path=[setup_requirement_path])
- if find_links:
- index.add_find_links((find_links,))
- req = pkg_resources.Requirement.parse(requirement)
- if index.obtain(req) is not None:
- best = []
- bestv = None
- for dist in index[req.project_name]:
- distv = dist.parsed_version
- if distv >= pkg_resources.parse_version('2dev'):
- continue
- if _final_version(distv):
- if bestv is None or distv > bestv:
- best = [dist]
- bestv = distv
- elif distv == bestv:
- best.append(dist)
- if best:
- best.sort()
- version = best[-1].version
-
-if version:
- requirement += '=='+version
-else:
- requirement += '<2dev'
-
-cmd.append(requirement)
-
-if is_jython:
- import subprocess
- exitcode = subprocess.Popen(cmd, env=env).wait()
-else: # Windows prefers this, apparently; otherwise we would prefer subprocess
- exitcode = os.spawnle(*([os.P_WAIT, sys.executable] + cmd + [env]))
-if exitcode != 0:
- sys.stdout.flush()
- sys.stderr.flush()
- print ("An error occurred when trying to install zc.buildout. "
- "Look above this message for any errors that "
- "were output by easy_install.")
- sys.exit(exitcode)
-
-ws.add_entry(eggs_dir)
-ws.require(requirement)
-import zc.buildout.buildout
-
-# If there isn't already a command in the args, add bootstrap
-if not [a for a in args if '=' not in a]:
- args.append('bootstrap')
-
-
-# if -c was provided, we push it back into args for buildout's main function
-if options.config_file is not None:
- args[0:0] = ['-c', options.config_file]
-
-zc.buildout.buildout.main(args)
-if not options.eggs: # clean up temporary egg directory
- shutil.rmtree(eggs_dir)
Deleted: grokproject/trunk/buildout.cfg
===================================================================
--- grokproject/trunk/buildout.cfg 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/buildout.cfg 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,14 +0,0 @@
-[buildout]
-newest = false
-develop = .
-parts =
- grokproject
- test
-
-[grokproject]
-recipe = zc.recipe.egg
-eggs = grokproject
-
-[test]
-recipe = zc.recipe.testrunner
-eggs = grokproject
Deleted: grokproject/trunk/setup.py
===================================================================
--- grokproject/trunk/setup.py 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/setup.py 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,44 +0,0 @@
-from setuptools import setup, find_packages
-
-_description = (
- "Script that creates a Grok project directory, installs Grok, the Grok "
- "Toolkit and the Zope Toolkit and sets up a complete skeleton for "
- "a new Grok web application."
- )
-
-long_description = (
- "===========\n"
- "Grokproject\n"
- "===========\n"
- "\n"
- "%s\n"
- "\n"
- ".. contents::\n"
- "\n"
- "Description\n"
- "===========\n"
- "\n" +
- open('README.txt').read() +
- '\n' +
- open('CHANGES.txt').read()
- ) % _description
-
-setup(
- name='grokproject',
- version='2.10.dev0',
- author='Grok Team',
- author_email='grok-dev at zope.org',
- url='http://grok.zope.org',
- download_url='http://pypi.python.org/pypi/grokproject',
- description=_description,
- long_description=long_description,
- license='ZPL',
- packages=find_packages(),
- include_package_data=True,
- zip_safe=False,
- install_requires=['PasteScript>=1.6'],
- test_suite='tests.test_suite',
- entry_points={
- 'console_scripts': ['grokproject = grokproject:main'],
- 'paste.paster_create_template': ['grok = grokproject:GrokProject']},
- )
Deleted: grokproject/trunk/tests.py
===================================================================
--- grokproject/trunk/tests.py 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/tests.py 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,130 +0,0 @@
-"""
-Grabs the tests in doctest
-
-Previously Taken virtually verbatim from zopeskel with permission (for ZPL)
-from Tarek Ziade. (c) Tarek Ziade
-"""
-__docformat__ = 'restructuredtext'
-
-import os
-import shutil
-import subprocess
-import sys
-import tempfile
-import unittest
-import doctest
-
-CURRENT_DIR = os.path.abspath(os.path.dirname(__file__))
-SHORTTESTFILE = os.path.join(os.path.dirname(__file__), 'shorttests')
-
-def rmdir(*args):
- dirname = os.path.join(*args)
- if os.path.isdir(dirname):
- shutil.rmtree(dirname)
-
-def read_sh(command, input=None):
- # XXX check for other platforms too?
- close_fds = not sys.platform.startswith('win')
- p = subprocess.Popen(
- command,
- stdin=subprocess.PIPE,
- stdout=subprocess.PIPE,
- stderr=subprocess.STDOUT,
- close_fds=close_fds
- )
- out, err_ = p.communicate(input)
- return out
-
-def sh(cmd):
- print cmd
- print read_sh(cmd)
-
-def ls(*args):
- dirname = os.path.join(*args)
- if os.path.isdir(dirname):
- filenames = os.listdir(dirname)
- for filename in sorted(filenames):
- print filename
- else:
- print 'No directory named %s' % dirname
-
-def cd(*args):
- dirname = os.path.join(*args)
- os.chdir(dirname)
-
-def cat(*args):
- filename = os.path.join(*args)
- if os.path.isfile(filename):
- print open(filename).read()
- else:
- print 'No file named %s' % filename
-
-def shorttests():
- return os.path.exists(SHORTTESTFILE)
-
-def maybe_mkdir(path):
- if shorttests() and os.path.isdir(path):
- return
- rmdir(path)
- os.makedirs(path)
-
-def maybe_rmdir(path):
- if shorttests() and os.path.isdir(path):
- return
- rmdir(path)
-
-def setup(test):
- eggsdir = os.path.join(tempfile.gettempdir(), 'grokproject-test-eggs')
- maybe_mkdir(eggsdir)
- test.globs['eggsdir'] = eggsdir
- test.globs['testdir'] = tempfile.mkdtemp()
-
-def teardown(test):
- maybe_rmdir(test.globs['eggsdir'])
- shutil.rmtree(test.globs['testdir'])
-
-
-def show_shorttests_message():
- if shorttests():
- print
- print 'WARNING: running shorttests.'
- print
- print ' This reduces the runtime of testruns by making use of'
- print ' a once filled eggs directory.'
- print ' If you want clean test runs with an empty eggs directory,'
- print ' remove the file "' + SHORTTESTFILE + '".'
- print
- print ' Running shorttests might lead to failing tests. Please run'
- print ' the full tests before submitting code.'
- print
- else:
- print
- print 'NOTE: running full tests.'
- print
- print ' If you want to reuse a prefilled eggs directory between'
- print ' test runs (which dramatically reduces runtime), create a'
- print ' file "' + SHORTTESTFILE + '" and rerun the tests.'
- print
-
-def test_suite():
- show_shorttests_message()
-
- globs = {
- 'ls': ls,
- 'cd': cd,
- 'cat': cat,
- 'sh': sh,
- 'read_sh': read_sh,
- 'current_dir': CURRENT_DIR,
- }
-
- suite = []
- suite.append(
- doctest.DocFileSuite(
- 'tests.txt',
- optionflags=doctest.ELLIPSIS | doctest.NORMALIZE_WHITESPACE,
- globs=globs,
- setUp=setup,
- tearDown=teardown,
- ))
- return unittest.TestSuite(suite)
Deleted: grokproject/trunk/tests.txt
===================================================================
--- grokproject/trunk/tests.txt 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/tests.txt 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,324 +0,0 @@
-Grokproject tests
-=================
-
-Go to a fresh test directory:
-
- >>> cd(testdir)
-
-Eggs are placed in our freshly created eggs directory:
-
- >>> import os.path
- >>> # Use a specific grok version, because 'current' will change at some
- >>> # point in the future.
- >>> executable = [os.path.join(current_dir, 'bin', 'grokproject')]
- >>> opts = ['--user=a', '--passwd=a', '--eggs-dir=' + eggsdir]
- >>> opts += ['--version-url=http://grok.zope.org/releaseinfo/1.3/versions.cfg']
- >>> sh(executable + opts + ['GrokExample'])
- ['...grokproject',
- '--user=a',
- '--passwd=a',
- '--eggs-dir=...grokproject-test-eggs',
- '--version-url=http://grok.zope.org/releaseinfo/1.3/versions.cfg',
- 'GrokExample']...
- Creating directory '...bin'.
- Creating directory '...parts'.
- Creating directory '...develop-eggs'.
- ...
- Develop: '...GrokExample...'
- ...
- Generated script '...paster'.
- Generated interpreter '...python-console'.
- Installing daemon.
- Generated script '...daemon'.
- Installing paster_ini_debug.
- Installing paster_ini_deploy.
- Installing i18n.
- i18n: setting up i18n tools
- Generated script '...i18nextract'.
- Generated script '...i18nmergeall'.
- Generated script '...i18nstats'.
- Generated script '...i18ncompile'.
- Installing mkdirs.
- mkdirs: created path: ...var
- mkdirs: created path: ...filestorage
- mkdirs: created path: ...log
- mkdirs: created path: ...blobstorage
- Installing site_zcml.
- Installing test.
- Generated script '...test'.
- Installing zope_conf_debug.
- ...
- Installing zope_conf_deploy.
- ...
- Installing zpasswd.
- Generated script '...zpasswd'.
- Installing interactive_debugger.
- Generated script '...interactive_debugger'.
- Installing data.
- Installing log.
- *************** PICKED VERSIONS ****************
- [versions]
- <BLANKLINE>
- *************** /PICKED VERSIONS ***************
- Creating directory ...GrokExample
- Running ...bootstrap.py...
- Running ...buildout...
- <BLANKLINE>
-
-Let's check the contents:
-
- >>> package_dir = os.path.join(testdir, 'GrokExample')
- >>> print open(os.path.join(package_dir, 'buildout.cfg')).read()
- [buildout]
- extends = http://grok.zope.org/releaseinfo/1.3/versions.cfg
- extends-cache = extends-cache
- include-site-packages = false
- develop = .
- ...
-
- >>> ls(package_dir)
- .installed.cfg
- bin
- bootstrap.py
- buildout.cfg
- develop-eggs
- etc
- extends-cache
- log
- parts
- setup.py
- src
- var
-
- >>> software_dir = os.path.join(package_dir, 'src', 'grokexample')
- >>> ls(software_dir)
- __init__.py
- app.py
- app_templates
- configure.zcml
- resource.py
- static
- tests
-
- >>> bin_dir = os.path.join(package_dir, 'bin')
- >>> ls(bin_dir)
- buildout
- daemon
- i18ncompile
- i18nextract
- i18nmergeall
- i18nstats
- interactive_debugger
- paster
- python-console
- test
- zpasswd
-
- >>> etc_dir = os.path.join(package_dir, 'parts', 'etc')
- >>> ls(etc_dir)
- debug.ini
- deploy.ini
- site.zcml
- zope.debug.conf
- zope.deploy.conf
-
-In the generated configuration files paths are set to local paths.
-We used a projectname with uppercase letters. This is respected by
-configuration files:
-
- >>> cat(etc_dir, 'zope.debug.conf')
- # Identify the component configuration used to define the site:
- site-definition .../GrokExample/parts/etc/site.zcml
- ...
-
-The eggs dir is filled now:
-
- >>> len(os.listdir(eggsdir)) > 100
- True
-
-The extends-cache directive results in cached versions of the referenced
-buildout files to support offline building. We know what the filename of the
-cached versions file for 1.3 will look like:
-
- >>> ls(os.path.join(package_dir, 'extends-cache'))
- 0e528124e9df4d3fad02dfc68147586e
- 354ba68f51f74190b8bfdc3d2686b6fb
- b88291ed0762c9dcbc55c7a7c7176bb1
-
-The password given is stored SSHA encoded:
-
- >>> site_zcml_in = os.path.join(package_dir, 'etc',
- ... 'site.zcml.in')
- >>> print open(site_zcml_in, 'rb').read()
- <configure xmlns="http://namespaces.zope.org/zope"
- ...
- <principal id="zope.manager"
- title="Manager"
- login="a"
- password_manager="SSHA"
- password="{SSHA}..."
- />
- ...
-
-
-Using i18n scripts
-------------------
-
-We can create a POT file out of our sources using the freshly
-generated `i18nextract`:
-
- >>> cmd = os.path.join(bin_dir, 'i18nextract')
- >>> output = read_sh(cmd)
- >>> print output
- domain:...'grokexample'
- ...
- output: '...grokexample.pot'
-
-The .pot file contains no specific entries right now. So let's add a
-source file with translatable content:
-
- >>> source = """
- ... from zope.i18nmessageid import MessageFactory
- ... _ = MessageFactory('grokexample')
- ...
- ... class SomeClassWithI18nableContent(object):
- ... title = _(u'mytitle')
- ... description = _(u'description')
- ... name = _(u'name')
- ... """
- >>> source_path = os.path.join(software_dir, 'translatable.py')
- >>> open(source_path, 'w').write(source)
-
-And rerun `bin/i18nextract`:
-
- >>> cmd = os.path.join(bin_dir, 'i18nextract')
- >>> output = read_sh(cmd)
-
-The translatable strings now appear in the generated .pot file:
-
- >>> pot_file = os.path.join(software_dir, 'locales', 'grokexample.pot')
- >>> print open(pot_file, 'r').read()
- ####...
- #: grokexample/translatable.py:6
- msgid "mytitle"
- msgstr ""
- <BLANKLINE>
- #: grokexample/translatable.py:7
- msgid "description"
- msgstr ""
- <BLANKLINE>
- #: grokexample/translatable.py:8
- msgid "name"
- msgstr ""
-
-Let's now create a translation for that (tiny) set of messages:
-
- >>> trans_dir_de = os.path.join(software_dir, 'locales', 'de',
- ... 'LC_MESSAGES')
- >>> os.makedirs(trans_dir_de)
-
-In this directory we create a copy of the original .pot file:
-
- >>> po_file_path = os.path.join(trans_dir_de, 'grokexample.po')
- >>> po_file = open(pot_file, 'r').read()
-
-We modify the translation to give some more interesting results:
-
- >>> po_file = po_file.replace('translatable.py:7\n',
- ... 'translatable.py:7\n#, fuzzy\n')
- >>> po_file = po_file.replace('"mytitle"\nmsgstr ""',
- ... '"mytitle"\nmsgstr "Mein Titel"')
- >>> po_file = po_file.replace('"name"\nmsgstr ""',
- ... '"name"\nmsgstr "Name"')
- >>> open(po_file_path, 'wb').write(po_file)
-
-We can merge all translations with bin/i18nmergeall:
-
- >>> cmd = os.path.join(bin_dir, 'i18nmergeall')
- >>> output = read_sh(cmd).split('\n')
- >>> print output[1]
- Merging language "de", domain "grokexample"
-
-We can see the status of translations calling bin/i18nstats:
-
- >>> cmd = os.path.join(bin_dir, 'i18nstats')
- >>> output = read_sh(cmd)
- >>> print output
- Language Total Done Not Done Fuzzy Done %
- ==========================================================
- de 3 1 1 1 33.33 %
-
-
-Using the generated `test` script
----------------------------------
-
-We can run tests:
-
- >>> cmd = os.path.join(bin_dir, 'test')
- >>> output = read_sh(cmd)
- >>> print 'Test:\n' + output
- Test:
- Running tests at level 1
- Running grokexample.tests.ZopeFanstaticBrowserLayer tests:
- Set up grokexample.tests.ZopeFanstaticBrowserLayer... in ... seconds.
- Running:
- ..
- Ran 2 tests with 0 failures and 0 errors in ... seconds.
- Running zope.testrunner.layer.UnitTests tests:
- Tear down grokexample.tests.ZopeFanstaticBrowserLayer in ... seconds.
- Set up zope.testrunner.layer.UnitTests in ... seconds.
- Running:
- .
- Ran 1 tests with 0 failures and 0 errors in ... seconds.
- Tearing down left over layers:
- Tear down zope.testrunner.layer.UnitTests in ... seconds.
- Total: 3 tests, 0 failures, 0 errors in ... seconds.
- <BLANKLINE>
-
-Using the generated `buildout` script
--------------------------------------
-
-We can call the `buildout` script of the freshly generated
-project. For this to work, we have to switch to the project directory
-first:
-
- >>> cd(package_dir)
- >>> cmd = os.path.join(bin_dir, 'buildout')
- >>> output = read_sh(cmd)
- >>> print output
- Develop: ...
- Updating app.
- Updating daemon.
- Updating paster_ini_debug.
- Updating paster_ini_deploy.
- Updating i18n.
- i18n: setting up i18n tools
- Updating mkdirs.
- Updating site_zcml.
- Updating test.
- Updating zope_conf_debug.
- Updating zope_conf_deploy.
- Updating zpasswd.
- Updating interactive_debugger.
- Updating data.
- Updating log.
- *************** PICKED VERSIONS ****************
- [versions]
- <BLANKLINE>
- *************** /PICKED VERSIONS ***************
- <BLANKLINE>
-
-Invalid project names
----------------------
-
-We check for invalid project names:
-
- >>> sh(executable + opts + ['360profile'])
- [...]
- Error: The chosen project name is not a valid package name: 360profile.
- Please choose a different project name.
-
- >>> sh(executable + opts + ['profile'])
- [...]
- Error: The package 'profile' is already on sys.path.
- Please choose a different project name.
Deleted: grokproject/trunk/upgrading.txt
===================================================================
--- grokproject/trunk/upgrading.txt 2013-03-01 15:43:05 UTC (rev 129958)
+++ grokproject/trunk/upgrading.txt 2013-03-01 15:43:12 UTC (rev 129959)
@@ -1,1060 +0,0 @@
-
-.. ABOUT THIS DOC
-.. It's a start for an upgrade guide to all the released versions
-.. of Grok and grokproject.
-..
-.. It's work-in-progress
-..
-
-.. contents:: Detailed docs
-
-
-Upgrading generated projects
-============================
-
-There have been a lot of changes between single releases of
-`grokproject`. Here is how you can upgrade your local grok project, if
-it was generated using an older version of `grokproject`.
-
-.. note:: The version numbers mentioned herein mean the versions of
- `grokproject`, not `grok` versions, except if explicitly
- said so. `grokproject` versions are mainly independent from
- the `grok` version used.
-
-Basics good to know
--------------------
-
-We start with some basic procedures nice to know about before actually
-doing the upgrade.
-
-Which version of `grokproject` is currently installed?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Newer versions of `grokproject` (since 1.0a2) support the
-``--version`` option. Run::
-
- $ grokproject --version
- 1.0a4
-
-This is the version of ``grokproject`` that will be used when you
-create a new project.
-
-If your installed ``grokproject`` does not support the ``--version``
-switch (you can also run ``grokproject --help`` to see what options
-are available), then you can lookup the ``grokproject`` script
-itself. It is a little Python script and the version number is written
-down in the script itself::
-
- $ which grokproject
- /usr/bin/grokproject
-
- $ less /usr/bin/grokproject
-
-will reveal what version of `grokproject` you have installed.
-
-.. _upgradetolatest:
-
-How can I upgrade to the latest ``grokproject`` version?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Run::
-
- $ easy_install -U grokproject
-
-This will fetch and install the latest version for you.
-
-.. note:: You need appropriate permissions to do so, maybe root or
- Administrator privileges. Use virtualenv_ if this is a
- problem for you.
-
-Upgrading the `grokproject` script will not upgrade your already
-generated projects.
-
-How can I bring the installed `grokproject` to a certain version?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you want to bring ``grokproject`` for instance to version 1.0a2,
-just run::
-
- $ easy_install grokproject==1.0a2
-
-This will fetch and install `grokproject` version 1.0a2 for you. All
-versions available can be found below.
-
-.. note:: You need appropriate permissions to do so, maybe root or
- Administrator privileges. Use virtualenv_ if this is a
- problem for you.
-
-
-.. _pingrokversion:
-
-How can I 'pin down' a certain `grok` version with a project?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Basically, you can run any `grok` version with any `grokproject`
-version.
-
-The common approach to pin a certain `grok` version down is to tell
-`buildout` to use it. This can be done by setting the version in
-`buildout.cfg`.
-
-In the ``[buildout]`` section of your `buildout.cfg` add a line like
-this::
-
- extends = http://grok.zope.org/releaseinfo/grok-1.0a1.cfg
-
-which will read the mentioned file from the grok site and use it as a
-`versions.cfg`. Browse http://grok.zope.org/releaseinfo/ to see what
-version files are available.
-
-Alternatively you can download this file and place it in your project
-root overwriting the old `versions.cfg` file. Make sure, however, to
-copy the packages pinned down by `grokproject` itself (near bottom of
-your original `versions.cfg`) over to the new versions.cfg.
-
-
-.. _whereistheconfig:
-
-Where are the configuration files?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Location of configuration files changed with different `grokproject`
-versions.
-
-* 1.0a4, 1.0a3:
- All configuration files are templates and can be found in
- ``etc/``.
-
-* 1.0a2, 1.0a1:
- All configuration files are in ``etc/``
-
-* 0.9, 0.8, 0.7, 0.6:
- deploy.ini, debug.ini:
- Do not exist.
-
- site.zcml:
- Inline in `buildout.cfg`
-
- zdaemon.conf, zope.conf:
- can be found in ``parts/zopectl/``
-
-* 0.4 or older:
- deploy.ini, debug.ini:
- Do not exist.
-
- site.zcml:
- Inline in `buildout.cfg`
-
- zdaemon.conf, zope.conf:
- can be found in ``parts/instance/``
-
-
-Which `grokproject` version was used for a **generated** project?
------------------------------------------------------------------
-
-If you have an already generated project you want to update, things
-are more difficult and likely to require some manual work.
-
-But before you can upgrade you have to know what version of
-`grokproject` was used when the project was created.
-
-Here is, how you can find out.
-
-1.0a4
-~~~~~
-
-Your project was generated by `grokproject` 1.0a4 if...
-
-* it contains a file ``etc/zope.conf.in`` *and*
-
-* this file contains a line saying::
-
- site-definition ${site_zcml:output}
-
- on top.
-
-1.0a3
-~~~~~
-
-Your project was generated by `grokproject` 1.0a3 if...
-
-* it contains a script ``zpasswd`` in ``bin/`` *and*
-
-* the ``versions.cfg`` contains also a line pinning ``grokui.admin``
- version.
-
-1.0a2 or 1.0a1
-~~~~~~~~~~~~~~
-
-Your project was generated by `grokproject` 1.0a2 or 1.0a1 if...
-
-* it does *not* contain a script ``zpasswd`` in ``bin/`` *and*
-
-* it *does* contain a script ``paster`` in ``bin/``
-
-The changes between 1.0a1 and 1.0a2 did not touch generated projects,
-but only options of the `grokproject` script itself.
-
-0.9
-~~~
-
-Your project was generated by `grokproject` 0.9 if...
-
-* it does *not* contain a script ``paster`` in ``bin/`` *and*
-
-* it does *not* contain a line with ``lovely.recipe`` in
- ``versions.cfg``.
-
-0.8
-~~~
-
-Your project was generated by `grokproject` 0.8 if...
-
-* it *does* contain a line with ``lovely.recipe`` in
- ``versions.cfg`` *and*
-
-* it does contain a script ``bootstrap.py``.
-
-0.7
-~~~
-
-Your project was generated by `grokproject` 0.7 if...
-
-* it does *not* contain a script ``bootstrap.py`` *and*
-
-* the ``buildout.cfg`` contains only one ``[data]`` section.
-
-0.6
-~~~
-
-Your project was generated by `grokproject` 0.6 if...
-
-* the ``buildout.cfg`` contains two ``[data]`` sections *and*
-
-* it contains a script ``i18nextract`` in the ``bin/`` directory.
-
-0.5.1
-~~~~~
-
-Your project was generated by `grokproject` 0.5.1 if...
-
-* it does *not* contain a script ``i18nextract`` in the ``bin/``
- directory *and*
-
-* it does *not* contain a section ``[zope3]`` in `buildout.cfg`.
-
-0.5
-~~~
-
-Your project was generated by `grokproject` 0.5 if...
-
-* it does contain a section ``[zope3]`` in `buildout.cfg` *and*
-
-* it does contain a script ``zopectl`` in the ``bin/`` directory.
-
-0.4 or older
-~~~~~~~~~~~~
-
-Your project was generated by `grokproject` 0.4 or older if...
-
-* it contains a script ``instance`` in the ``bin/`` directory.
-
-
-How can I upgrade a generated project from version X to version Y?
-------------------------------------------------------------------
-
-If you found out with which `grokproject` version your project was
-created with, you can start the real upgrading.
-
-The basic and fastest way to upgrade:
-
-Say, we have an old project ``Cave`` which was generated by
-``grokproject`` 1.0a1, we want to upgrade to 1.0a4, and the old project
-resides in ``old/Cave/``.
-
-1) Bring ``grokproject`` to the target version (`see above
- <#upgradetolatest>`_)::
-
- $ easy_install grokproject==1.0a4
-
-2) With this ``grokproject`` create a new project (at a new location)
- with the *same name* as the one to upgrade. You might want to use the
- ``--grokversion`` option to use the same ``grok`` version as your
- old project::
-
- $ grokproject --grokversion=1.0a3 Cave
-
- Here we use ``grokproject`` 1.0a4 to create a project that uses
- ``grok`` 1.0a3. Yes, this can be confusing.
-
-3) In your freshly created project remove the generated sources under
- ``src/<projname>/``, i.e. the complete ``<projname>`` folder::
-
- $ rm -rf Cave/src/cave
-
-4) Copy the sources of src/<projname>, i.e. the ``<projname>`` folder
- from your old project over to the new project.
-
- $ cp -ar old/Cave/src/cave Cave/src
-
-5) Rerun buildout in your new project::
-
- $ cd Cave
- $ bin/buildout
-
- Upgrade finished.
-
-This procedere, however, might fail for certain version bumps, where
-also the mean sources (under ``src/<projname>``) have to be changed. The
-necessary additional changes are described below.
-
-In our example, for instance, we have to remove the module
-``startup.py`` from the sources.
-
-Further problems can arise, if you manually changed the main
-configuration files (i.e. in `etc/` or `parts/`, the ``buildout.cfg``
-or ``setup.py``). In this case you have to redo your changes in the
-new project.
-
-If you use version control, take care of any VC stuff copied over like
-hidden subversion directories.
-
-
-Additional Upgrade Steps (fast lane)
-------------------------------------
-
-These steps have to be performed additionally to the above mentioned
-procedure.
-
-
-Pin the `grok` version used in your old project
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The freshly generated grokproject will by default use the latest grok
-version available. This might cause problems with the code of your old
-project.
-
-To use the `grok` version your old project used, lookup the `grok`
-version your old project used at top of the `versions.cfg` file of
-your old project and set this in your upgraded project as described
-`above <#pingrokversion>`_.
-
-
-Eventually remove `startup.py` from sources
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If your sources (i.e. the package stored in `<src/myproject>` contain
-a module `startup.py`, which was not changed since creation, you can
-safely remove it.
-
-This module was only generated for projects created with `grokproject`
-versions 1.0a1/1.0a2.
-
-
-Check parameters in configuration files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Check the parameters set in the configuration files to match the
-settings of your old project.
-
-See `Where are the configuration files?`_ to find out where the configuration
-files in your old project can be found.
-
-In you new project they can be found as templates in the `etc/`
-directory.
-
-
-Manually upgrading (detailed)
------------------------------
-
-If you want to perform the single changes between ``grokproject``
-releases manually, here is how to do this.
-
-
-from 1.0a3 to 1.0a4
-~~~~~~~~~~~~~~~~~~~
-
-The fastest way might be to create a new project with the same name
-with ``grokproject`` 1.0a4 and then replace the complete
-``src/<projname>`` tree of your freshly generated stuff with the
-contents of the ``src/<projectname>`` tree from your old project.
-
-If you instead want to apply all changes manually, then in your old
-project follow these steps:
-
-* remove the line pinning ``grokui.admin`` near the end of
- ``versions.cfg``.
-
-* replace the line in section ``[handler_accesslog]`` in
- ``etc/debug.ini.in`` starting with ``args =`` with the following
- line::
-
- args = (os.path.join(r'${buildout:directory}', 'parts', 'log',
- 'access.log'), 'a')
-
-* do the same in file ``etc/deploy.ini.in``.
-
-* in ``etc/zope.conf.in`` replace::
-
- site-definition ${buildout:directory}/etc/site.zcml
-
- with::
-
- site-definition ${site_zcml:output}
-
- and replace::
-
- path ${buildout:directory}/parts/data/Data.fs
-
- with::
-
- path ${data:path}
-
-* in `buildout.cfg` you might add a line to the ``[buildout]`` section
- reading::
-
- find-links = http://download.zope.org/distribution/
-
- But read section `Using find-links`_ below.
-
-Rerun ``buildout`` afterwards and you should be done.
-
-
-from 1.0a2 to 1.0a3
-~~~~~~~~~~~~~~~~~~~
-
-* in ``buildout.cfg`` change the ``parts`` line near top from::
-
- parts = eggbasket app i18n test data log
-
- to::
-
- parts = eggbasket app i18n test data log zpasswd
- zope_conf site_zcml zdaemon_conf deploy_ini debug_ini
-
-* in ``buildout.cfg`` add the following sections::
-
- # This section is named so that the zpasswd utility is
- # called `zpasswd`
- [zpasswd]
- recipe = z3c.recipe.dev:script
- eggs = <projname>
- module = zope.app.server.zpasswd
- method = main
-
- [zope_conf]
- recipe = z3c.recipe.template
- input = etc/zope.conf.in
- output = ${buildout:parts-directory}/etc/zope.conf
-
- [site_zcml]
- recipe = z3c.recipe.template
- input = etc/site.zcml.in
- output = ${buildout:parts-directory}/etc/site.zcml
-
- [zdaemon_conf]
- recipe = z3c.recipe.template
- input = etc/zdaemon.conf.in
- output = ${buildout:parts-directory}/etc/zdaemon.conf
-
- [deploy_ini]
- recipe = z3c.recipe.template
- input = etc/deploy.ini.in
- output = ${buildout:parts-directory}/etc/deploy.ini
-
- [debug_ini]
- recipe = z3c.recipe.template
- input = etc/debug.ini.in
- output = ${buildout:parts-directory}/etc/debug.ini
-
- and make sure to replace ``<projname>`` in the ``[zpasswd]`` section
- with the egg name of your project (for instance ``sample`` if your
- project was named ``Sample``).
-
-* in ``setup.py``:
-
- * add ``grokcore.startup`` to the required dependencies.
-
- * in the entry-point definitions section (near end) replace::
-
- [console_scripts]
- <projname>-debug = <projname>.startup:interactive_debug_prompt
- <projname>-ctl = <projname>.startup:zdaemon_controller
- [paste.app_factory]
- main = <projname>.startup:application_factory
-
- with::
-
- [console_scripts]
- <projname>-debug = grokcore.startup:interactive_debug_prompt
- <projname>-ctl = grokcore.startup:zdaemon_controller
- [paste.app_factory]
- main = grokcore.startup:application_factory
-
- and of course fill in your real projects eggname (lowercase
- projectname) instead of ``<projname>``.
-
-* in ``versions.cfg`` near bottom, where all `grokproject` specific
- versions are pinned, replace::
-
- # Here we pin the recipes used in the buildout.cfg
- z3c.recipe.i18n = 0.5.0
- z3c.recipe.eggbasket = 0.4.0
- zc.buildout = 1.0.6
- zc.recipe.egg = 1.1.0b1
- zc.recipe.filestorage = 1.0.1
- zc.recipe.testrunner = 1.0.0
- zc.zodbrecipes = 0.4.0
- zc.zope3recipes = 0.7.0
-
- with::
-
- # Here we pin the recipes and other packages that are not in the
- # downloaded versions.cfg of grok
- Paste = 1.7.2
- PasteDeploy = 1.3.2
- PasteScript = 1.7.3
- setuptools = 0.6c9
- z3c.evalexception = 2.0
- z3c.recipe.eggbasket = 0.4.1
- z3c.recipe.i18n = 0.5.0
- z3c.recipe.template = 0.1
- zc.buildout = 1.1.1
- zc.recipe.egg = 1.1.0
- zc.recipe.filestorage = 1.0.1
- grokcore.startup = 0.2
-
-
-
-Upgrading already created projects
-----------------------------------
-
-`grokproject` received a lot of changes during releases. This also
-touched the structure of generated projects. For example there was
-support for paster_ introduced and the generation of configuration
-files changed heavily.
-
-Here we will explain, what changes were done (and why) and how you can
-apply those changes to your existing projects.
-
-
-Paster and `startup.py`
-~~~~~~~~~~~~~~~~~~~~~~~
-
-With `grokproject` 1.0a1 we introduced paster_ support. This means,
-that the whole grok application is now by default served as a WSGI_
-application served by paster_.
-
-If your project has no `paster` script in ``bin/`` then you still lack
-paster support.
-
-To make paster support available in an existing project, follow these
-steps:
-
-1) Define entry points for paster, the ZDaemon controller and the debug
- prompt.
-
- In the `setup.py` of your project replace the (empty) entry points
- definition (near end of file) by something like this::
-
- entry_points = """
- [paste.app_factory]
- main = grokcore.startup:application_factory
- """,
-
- If you also want `ZDaemon` controlled starter scripts
- (`bin/mypkg-ctl`, `bin/mypkg-debug`) add also the following entry
- points for console scripts (they are not needed to run plain
- paster) and read `Adding ZDaemon control scripts`_::
-
- entry_points = """
- [console_scripts]
- <proj_mod_name>-debug = grokcore.startup:interactive_debug_prompt
- <proj_mod_name>-ctl = grokcore.startup:zdaemon_controller
- [paste.app_factory]
- main = grokcore.startup:application_factory
- """,
-
- Please use the upper *or* the latter snippet, not both.
-
- Make sure to replace ``<proj_mod_name>`` with the module name of
- your project. This name equals to the directory name of the
- directory holding your sources in ``src/``. So if you have a
- directory ``src/myproj`` then the name will be ``myproj``. Normally
- this is the lowercase version of your project name. Please note that
- this name is case-sensitive.
-
- The entry points we defined here can be used by certain buildout
- recipes to generate scripts automatically. Note, that the
- ``[console_scripts]`` are not necessary for paster but buildout to
- create simple wrapper scripts for starting our application.
-
- The entry points above determine, where other components (like
- paster) can find certain python modules. For example we tell, that
- there is a paster-compatible application factory available named
- ``application_factory`` and placed in the ``grokcore.startup``
- module. This module, of course, must be available during startup.
-
- Let's care for this now.
-
-2) Require `grokcore.startup`.
-
- Add an entry ``'grokcore.startup'`` to the list of
- ``install_requires`` in your project's `setup.py`.
-
- If you want your own/special WSGI configuration, then you can do so
- and skip this step (see below for further details).
-
-3) Pin down versions of extra packages (optional).
-
- To use paster we need some extra packages. The versions of those
- packages can be pinned down in file ``versions.cfg`` or in a special
- ``[versions]`` section of your `buildout.cfg`.
-
- Add::
-
- Paste = 1.7.2
- PasteDeploy = 1.3.2
- PasteScript = 1.7.3
- z3c.evalexception = 2.0
- grokcore.startup = 0.2
-
- The version numbers pinned here are the ones used by latest
- `grokproject` as time of writing (1.0a4). When you read this newer
- versions might be in use.
-
- You can remove (because we will not use it anymore)::
-
- zc.zodbrecipes = 0.4.0
- zc.zope3recipes = 0.7.0
-
-4) Create a separate `site.zcml` file.
-
- When we use paster we also have to provide a separate `site.zcml`
- file, as we have to refer to it in our paster configurations.
-
-5) Modify `buildout.cfg` to make the changes active.
-
- Right now our modified project is likely to be broken. We have to
- tell buildout that we like to have a paster-powered application.
-
- * Remove ``zopectl`` from the ``parts`` in `buildout.cfg` (near
- top).
-
- Also remove the complete ``[zopectl]`` section from `buildout.cfg`
- as we do not use it anymore (optional).
-
- * In the ``[app]`` section of `buildout.cfg` copy the definition of
- ``site.zcml`` (the one which consists of many lines) to a separate
- file. We might need this later on.
-
- * Replace the whole ``[app]`` section with the following::
-
- [app]
- recipe = zc.recipe.egg
- eggs = <proj_egg_name>
- z3c.evalexception>=2.0
- Paste
- PasteScript
- PasteDeploy
- interpreter = python-console
-
- where instead ``<proj_egg_name>`` you should insert the name of
- your project egg (as defined near top of `setup.py`). It is
- normally the project name.
-
- * Add a ``[log]`` section.
-
- Add `log` to the list of parts near the beginning of
- `buildout.cfg`.
-
- Add the following somewhere in `buildout.cfg`::
-
- [log]
- recipe = zc.recipe.filestorage
-
- This will generate a directory ``log/`` in the ``parts/``
- directory of your project.
-
-6) Configuration files: templated or manually
-
- From here we can go two distinct ways: we can generate the still
- missing configuration files manually or go a quicker way by letting
- buildout do it for us using templates.
-
- If you prefer the latter, read on in section Setting up
- configuration from templates below. This is also the recommended
- approach as using templates for configuration you get configurations
- usable in a version controlled environment (SVN or so) without
- hardcoded paths.
-
- Otherwise, or if you like to dig deeper into the details of
- configuration, read on here.
-
-7) Create a `deploy.ini`
-
- If we now rerun `bin/buildout`, there should be generated an
- executable script `bin/paster`.
-
- This, however, is not enough as we still need the configuration
- files for our application to be served. We must tell paster where to
- find the WSGI application and how it should be configured.
-
- This is normally done in a file called `deploy.ini` or similar and
- it can be very short::
-
- # deploy.ini
- [app:main]
- use = egg:<proj_egg_name>
-
- [server:main]
- use = egg:Paste#http
- host = 127.0.0.1
- port = 8080
-
- [DEFAULT]
- # set the name of the zope.conf file
- zope_conf = %(here)s/zope.conf
-
- Again, replace ``<proj_egg_name>`` with the egg name of your
- project.
-
- This file can be placed where ever you like. Latest grokprojects
- generate the file automatically from templates placed in ``etc/``
- and write the generated file to ``parts/etc/deploy.ini``.
-
-
-8) Generate a `zope.conf`
-
- As we can see in the `deploy.ini` above there is a reference to
- another configuration file `zope.conf`. This is needed by the
- application factory to configure the grok application we want to
- serve.
-
- Let's create a simple one::
-
- # zope.conf
- # Identify the component configuration used to define the site:
- site-definition <project_path>/parts/etc/site.zcml
-
- <zodb>
- # Standard Filestorage
- <filestorage>
- path <proj_path>/parts/data/Data.fs
- </filestorage>
- </zodb>
-
- <eventlog>
- # This sets up logging to a file.
- # The "path" setting can be a relative or absolute
- # filesystem path.
- <logfile>
- path <proj_path>/parts/log/z3.log
- formatter zope.exceptions.log.Formatter
- </logfile>
- </eventlog>
-
- # Comment this line to disable developer mode. This should be done in
- # production
- devmode on
-
- Of course, here we have to replace all ocurrences of ``<proj_path>``
- with the absolute path to our project directory.
-
- This file (`zope.conf`) has to be placed in the same directory as
- `deploy.ini`.
-
- Note, that the hardcoded absolute paths in here make it difficult to
- use this configuration in a shared or version controlled development
- environment. You can use templates (see below) to circumvent this.
-
-9) Create a `site.zcml`
-
- The `zope.conf` contains a reference to a file called `site.zcml`,
- where the configuration of the component architechture is stored
- in. This file is also needed on startup, so we create a simple
- `site.zcml`::
-
- <configure xmlns="http://namespaces.zope.org/zope"
- i18n_domain="MYPKG">
-
- <include package="MYPKG" />
- <configure i18n_domain="MYPKG">
- <unauthenticatedPrincipal id="zope.anybody"
- title="Unauthenticated User" />
- <unauthenticatedGroup id="zope.Anybody"
- title="Unauthenticated Users" />
- <authenticatedGroup id="zope.Authenticated"
- title="Authenticated Users" />
- <everybodyGroup id="zope.Everybody"
- title="All Users" />
- <principal id="zope.manager"
- title="Manager"
- login="grok"
- password_manager="SHA1"
- password="e3756f86739bd029629243732eb682db005a7541f7509622"
- />
- <!-- Replace the following directive if you do not want
- public access -->
- <grant permission="zope.View"
- principal="zope.Anybody" />
- <grant permission="zope.app.dublincore.view"
- principal="zope.Anybody" />
-
- <role id="zope.Manager" title="Site Manager" />
- <role id="zope.Member" title="Site Member" />
- <grantAll role="zope.Manager" />
- <grant role="zope.Manager"
- principal="zope.manager" />
- </configure>
- </configure>
-
- Please replace ``MYPKG`` with the name of your toplevel source
- package, which is normally the lowercase projectname. In other
- words: if your project contains a directory ``src/mypackage/`` then
- replace ``MYPKG`` with ``mypackage`` in the above template.
-
- The SHA1-hashed password above is ``grok`` in plain text (see also
- "`Adding zpasswd script`_" below).
-
- Put this file (`site.zcml`) at the location given in `zope.conf`
- above.
-
- Now you should be able to start paster. Try::
-
- $ bin/paster serve deploy.ini
-
- and if everything works okay, you should be able to browse
- ``http://localhost:8080/``. The username/password with the
- `site.zcml` configuration given above is ``grok`` and ``grok``.
-
-If you now also want ZDaemon controlled starter scripts (see step 1),
-read on below at `Adding ZDaemon control scripts`_.
-
-Defining your own WSGI configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. _conftemplates:
-
-Configuration templates
------------------------
-
-With `grokproject` 1.0a3 we introduced generation of all main
-configuration files (`deploy.ini`, `debug.ini`, `zope.conf`,
-`site.zcml`, `zdeamon.conf`) via template files.
-
-The template files are by default put in the `etc/` directory of a
-freshly generated project and have the ``.in`` filename
-extension. They are read by a special recipe used by `buildout` and
-generate the real configuration files in the `parts/etc/` directory of
-your project when you run `buildout`. See
-`collective.recipe.template`_ for deeper insights.
-
-With the configuration templates enabled, `buildout` reads the
-configuration templates pointed to in `buildout.cfg`, expands any
-variables therein and writes the result to the real configuration
-files in `parts/etc/`.
-
-Using templates has a lot of advantages over manually writing
-configuration files. Most notably you can avoid hardcoded paths, so
-that the same configuration will work also on computers of other
-developers/users without changes.
-
-To make all this happen, you need the configuration file templates
-normally generated by `grokproject` and some new entries in
-`buildout.cfg`.
-
-We modify `buildout.cfg` so that the configuration files are looked up
-in the `etc/` subdirectory of our project. For each configuration file
-we give the template file and the location, where the resulting file
-should be created.
-
-Add the following sections to `buildout.cfg`::
-
- [zope_conf]
- recipe = collective.recipe.template
- input = etc/zope.conf.in
- output = ${buildout:parts-directory}/etc/zope.conf
-
- [site_zcml]
- recipe = collective.recipe.template
- input = etc/site.zcml.in
- output = ${buildout:parts-directory}/etc/site.zcml
-
- [zdaemon_conf]
- recipe = collective.recipe.template
- input = etc/zdaemon.conf.in
- output = ${buildout:parts-directory}/etc/zdaemon.conf
-
- [deploy_ini]
- recipe = collective.recipe.template
- input = etc/deploy.ini.in
- output = ${buildout:parts-directory}/etc/deploy.ini
-
- [debug_ini]
- recipe = collective.recipe.template
- input = etc/debug.ini.in
- output = ${buildout:parts-directory}/etc/debug.ini
-
-Each of these section names (``zope_conf``, ``site_zcml``, etc.) must
-also added to the list of ``parts`` near top of `buildout.cfg`, so
-that is might read similar to this::
-
- parts = eggbasket app i18n test data log zpasswd
- zope_conf site_zcml zdaemon_conf deploy_ini debug_ini
-
-Now all we need to make this work are the configuration file templates
-placed in an `etc/` subdirectory.
-
-Generating configuration templates using `grokproject`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If the configuration files of your old project were not modified too
-heavily, you can easily generate all configuration files like this:
-
-1) Upgrade `grokproject` to the latest release (see above)::
-
- $ easy_install -U grokproject
-
-2) Create a Grok project with the same projectname as the project you
- want to upgrade::
-
- $ grokproject Cave
-
- Afterwards you have the complete bunch of configuration templates
- in the `etc/` directory of your project.
-
-3) Copy the complete `etc/` directory of you freshly generated project
- over to the old project:
-
- $ cp -r Cave/etc old_proj/Cave/
-
-You might want to check, whether the settings in the configuration
-files (ports, passwords, etc.) meet your old project's settings.
-
-The configuration files hide in older projects somewhere in the
-`parts/` directory of your project.
-
-Please note that any terms like ``${buildout:directory}`` in template
-files are expanded when running buildout. Do not overwrite them with
-static absolute paths from your old configuration file unless you know
-what you are doing.
-
-If you rerun `buildout` afterwards, the new configuration files should
-be written to `parts/etc/` in your project.
-
-If you want to change the configuration files (not the templates),
-consider modifying the templates instead as on the next run of
-`buildout` your direct changes to files in `parts/` are likely to
-vanish while changes to the templates will go to the configuration
-files generated there.
-
-
-.. _findlinks:
-
-Using ``find-links``
---------------------
-
-Some versions of `grokproject` generated an additional line in
-`buildout.cfg` saying::
-
- find-links = http://download.zope.org/distribution/
-
-This line tells buildout to look for eggs not only in the standard
-Python PyPI (=Python Package Index, located at
-http://pypi.python.org/ ) but also in other locations like the Zope
-package index.
-
-The Zope PyPI was planned in the beginning as a pure mirror of the
-canonical Python PyPI, but was soon filled also with eggs not
-available at the standard PyPI. This means, that you still cannot get
-certain eggs from PyPI which are still hosted at the Zope site only.
-
-Furthermore the Zope PyPI was planned to serve as a fallback in case
-of outages of the central PyPI site and it should deliver eggs faster.
-
-Usage of ``find-links`` is quite common in the Zope2 and Plone world
-but it is meanwhile deprecated in the Zope 3 (aka ZTK, Zope Toolkit)
-world.
-
-As developers wanted to concentrate on a single repository shared with
-the whole Python community, all egg authors should now host their
-packages on http://pypi.python.org/ only.
-
-To enforce this usage pattern, people are strongly encouraged *not* to
-use the above `find-links` statement any more.
-
-Unfortunately, there is still a little number of eggs available from
-the Zope package index only, which also includes some eggs some
-`megrok` packages depend on. If you want this `megrok` packages to
-work (namely `megrok.form`), you have to lookup the Zope package index
-or in other words: you have to use the above `find-links` statement.
-
-As a rule of thumb you should try to cope without it. If, however, you
-get some errors during running `buildout` telling that some packages
-cannot be found, add the `find-links` statement.
-
-
-.. _zdaemon:
-
-Adding ZDaemon control scripts
-------------------------------
-
-To start a daemon that serves your grok application, all versions of
-`grokproject` generate a suitable script in the `bin/` directory.
-
-Recent versions of `grokproject` generate scripts in the `bin/`
-directory called `<proj-name>-ctl` and `<proj-name>-debug` where
-``<proj-name>`` is the lowercase project name.
-
-These scripts can be used like the well-known init-scripts on Unix
-systems. I.e. you can say something like::
-
- $ ./bin/myproj-ctl start|stop|restart|fg|--help
-
-This is functionality actually provided by the `ZDaemon` software,
-also a part of the Zope software.
-
-In oldest versions, this script was called ``instance``.
-
-With introducing paster, the way of generating those scripts
-changed. So you have to care for this if upgrading.
-
-
-
-
-
-.. _zpasswd:
-
-Adding ``zpasswd`` script
--------------------------
-
-You can add a ``zpasswd`` script (if you still lack one) by modifying
-the `buildout.cfg` in your project.
-
-1) Add ``zpasswd`` to the list of parts near top of the file.
-
-2) Add the following ``zpasswd`` section somewhere in `buildout.cfg`,
- maybe at the end::
-
- # This section is named so that the zpasswd utility is
- # called `zpasswd`
- [zpasswd]
- recipe = z3c.recipe.dev:script
- eggs = <proj_egg_name>
- module = zope.app.server.zpasswd
- method = main
-
- Make sure to replace ``<proj_egg_name>`` by the name of your
- project egg as set it ``setup.py`` (normally the project name).
-
-Rerun `bin/buildout` and the script should be generated.
-
-.. _collective.recipe.template:
- http://pypi.python.org/pypi/collective.recipe.template
-
-.. _paster: http://pypi.python.org/pypi/Paste
-
-.. _virtualenv: http://pypi.python.org/pypi/virtualenv
-
-.. _WSGI: http://www.wsgi.org/wsgi/
More information about the checkins
mailing list