If you installed or compiled a version of Python specifically for the purposes of Plone development, and you did not install anything else globally, you can skip this step.

If, however, you want to use an operating system-provided Python installation, or you intend to install anything into the global Python environment, you should create an isolated Python environment for Plone development using Virtualenv by executing the following steps:

This will install a 'clean' Python binary in plone-python/bin/python. The --no-site-packages ensures no global site packages 'bleed' into the environment.

If you installed or compiled a version of Python specifically for the purposes of Plone development, and you did not install anything else globally, you can skip this step.

If, however, you want to use an operating system-provided Python installation, or you intend to install anything into the global Python environment, you should create an isolated Python environment for Plone development using Virtualenv by executing the following steps:

This will install a 'clean' Python binary in plone-python/bin/python. The --no-site-packages ensures no global site packages 'bleed' into the environment.

Besides the buildout configuration and bootstrap files, a buildout consists of a number of directories and files, many of which are created and managed by Buildout and various recipes.

We always should put our build under source control, using a version control system such as Subversion or Git. As a rule of thumb, however, we should not version control any files generated by buildout. This usually means adding the relevant files or directories to the 'ignore' list for our source code management system.

Inside a Plone development buildout, we may find the following files and directories:

To save bandwidth, disk space, and build time, it is a good idea to share third party files between buildouts. Buildout allows us to specify shared directories for eggs, downloads, and remotely extended buildout files (such as known good version sets).

Buildout defaults are set in a file found in ~/.buildout/default.cfg, where ~ is our home directory.

We must first create the .buildout directory inside our home directory if it does not already exist. Inside .buildout, we then create the directories eggs, downloads, and extends to store the various types of downloads, and a file called default.cfg, containing:

[buildout]
eggs-directory = /path/to/.buildout/eggs
download-cache = /path/to/.buildout/downloads
extends-cache  = /path/to/.buildout/extends

The default.cfg file can be used for other defaults if necessary. It behaves as if it is implicitly extended by any buildout you run.

Distributions using Setuptools/Distribute – include those we will write starting from Chapter 5, Developing a Site Strategy and use as develop eggs—consisting of a directory with a top-level setup.py file, and relevant source code, documentation, and other files.

setup.py contains metadata about the distribution itself, and declares its current version as well as any dependencies. Dependencies can be specified down to particular versions (such as ">=0.2,<1.0" means "later than version 0.2 but earlier than version 1.0"). Here is a sample setup.py file:

from setuptools import setup, find_packages
import os

version = '1.0'

setup(name='my.package',
      version=version,
      description="Description of my package",
      long_description=open("README.txt").read() + "\n" +
                   open(os.path.join("docs", "HISTORY.txt")).read(),
      author='Martin Aspeli',
      author_email='[email protected]',
      license='GPL',
      packages=find_packages(exclude=['ez_setup']),
      namespace_packages=['my'],
      include_package_data=True,
      zip_safe=False,
      install_requires=[
          'setuptools',
          'some.package >= 1.0',
      ],
      )

Here:

When a distribution is installed, Setuptools/Distribute will attempt to fulfill dependencies listed under install_requires by downloading and installing them if necessary. It will look for distributions on PyPI by default, but an alternative index can be specified if necessary, and secondary 'find-links' may be listed in the distribution itself.

It is possible to use setup.py to install a distribution into the global site packages of a given Python interpreter:

$ python setup.py install

To install a develop egg instead, we can run:

$ python setup.py develop

This creates a placeholder file that links to the distribution's source code, allowing it to be added to the Python path at runtime.

New packages can be released as source distributions, which are just zip files of the package with some additional metadata. We can build a source distribution of a package with:

$ python setup.py sdist

The new distribution will be placed in the dist subdirectory, which will be created if necessary.

Distributions can be uploaded to PyPI through a setup.py command:

$ python setup.py egg_info -RDb "" sdist register upload

You will be asked to specify or create a PyPI account if this is the first time you run this command. The login details are stored in the .pypirc file in your home directory.

The easy_install script searches PyPI or a similar index for distribution to download and install into the global Python environment. The latest valid versions of any dependencies will be included automatically. For example, we installed Virtualenv with:

$ easy_install -U virtualenv

Some distributions have optional dependencies known as extras. These can be installed using square bracket notation, for example:

$ easy_install -U my.package [someextra]

The same notation is supported in the install_requires line for dependencies. For example, a distribution that wanted to declare an extra called test that added a dependency on plone.testing with the z2 extra could add the following in its setup.py file:

      extras_require={
          'test': ['plone.testing[z2]',]
      },

Distributions can contain metadata about included plugins using a mechanism called entry points. This allows code to discover these plugins at runtime. Entry points are listed in setup.py, under the entry_points argument. For example, some Plone add-ons use an entry point like this to automatically register their configuration with Plone:

      entry_points="""
      [z3c.autoinclude.plugin]
      target = plone
      """,

Besides the buildout configuration and bootstrap files, a buildout consists of a number of directories and files, many of which are created and managed by Buildout and various recipes.

We always should put our build under source control, using a version control system such as Subversion or Git. As a rule of thumb, however, we should not version control any files generated by buildout. This usually means adding the relevant files or directories to the 'ignore' list for our source code management system.

Inside a Plone development buildout, we may find the following files and directories:

To save bandwidth, disk space, and build time, it is a good idea to share third party files between buildouts. Buildout allows us to specify shared directories for eggs, downloads, and remotely extended buildout files (such as known good version sets).

Buildout defaults are set in a file found in ~/.buildout/default.cfg, where ~ is our home directory.

We must first create the .buildout directory inside our home directory if it does not already exist. Inside .buildout, we then create the directories eggs, downloads, and extends to store the various types of downloads, and a file called default.cfg, containing:

[buildout]
eggs-directory = /path/to/.buildout/eggs
download-cache = /path/to/.buildout/downloads
extends-cache  = /path/to/.buildout/extends

The default.cfg file can be used for other defaults if necessary. It behaves as if it is implicitly extended by any buildout you run.

Distributions using Setuptools/Distribute – include those we will write starting from Chapter 5, Developing a Site Strategy and use as develop eggs—consisting of a directory with a top-level setup.py file, and relevant source code, documentation, and other files.

setup.py contains metadata about the distribution itself, and declares its current version as well as any dependencies. Dependencies can be specified down to particular versions (such as ">=0.2,<1.0" means "later than version 0.2 but earlier than version 1.0"). Here is a sample setup.py file:

from setuptools import setup, find_packages
import os

version = '1.0'

setup(name='my.package',
      version=version,
      description="Description of my package",
      long_description=open("README.txt").read() + "\n" +
                   open(os.path.join("docs", "HISTORY.txt")).read(),
      author='Martin Aspeli',
      author_email='[email protected]',
      license='GPL',
      packages=find_packages(exclude=['ez_setup']),
      namespace_packages=['my'],
      include_package_data=True,
      zip_safe=False,
      install_requires=[
          'setuptools',
          'some.package >= 1.0',
      ],
      )

Here:

When a distribution is installed, Setuptools/Distribute will attempt to fulfill dependencies listed under install_requires by downloading and installing them if necessary. It will look for distributions on PyPI by default, but an alternative index can be specified if necessary, and secondary 'find-links' may be listed in the distribution itself.

It is possible to use setup.py to install a distribution into the global site packages of a given Python interpreter:

$ python setup.py install

To install a develop egg instead, we can run:

$ python setup.py develop

This creates a placeholder file that links to the distribution's source code, allowing it to be added to the Python path at runtime.

New packages can be released as source distributions, which are just zip files of the package with some additional metadata. We can build a source distribution of a package with:

$ python setup.py sdist

The new distribution will be placed in the dist subdirectory, which will be created if necessary.

Distributions can be uploaded to PyPI through a setup.py command:

$ python setup.py egg_info -RDb "" sdist register upload

You will be asked to specify or create a PyPI account if this is the first time you run this command. The login details are stored in the .pypirc file in your home directory.

The easy_install script searches PyPI or a similar index for distribution to download and install into the global Python environment. The latest valid versions of any dependencies will be included automatically. For example, we installed Virtualenv with:

$ easy_install -U virtualenv

Some distributions have optional dependencies known as extras. These can be installed using square bracket notation, for example:

$ easy_install -U my.package [someextra]

The same notation is supported in the install_requires line for dependencies. For example, a distribution that wanted to declare an extra called test that added a dependency on plone.testing with the z2 extra could add the following in its setup.py file:

      extras_require={
          'test': ['plone.testing[z2]',]
      },

Distributions can contain metadata about included plugins using a mechanism called entry points. This allows code to discover these plugins at runtime. Entry points are listed in setup.py, under the entry_points argument. For example, some Plone add-ons use an entry point like this to automatically register their configuration with Plone:

      entry_points="""
      [z3c.autoinclude.plugin]
      target = plone
      """,

To save bandwidth, disk space, and build time, it is a good idea to share third party files between buildouts. Buildout allows us to specify shared directories for eggs, downloads, and remotely extended buildout files (such as known good version sets).

Buildout defaults are set in a file found in ~/.buildout/default.cfg, where ~ is our home directory.

We must first create the .buildout directory inside our home directory if it does not already exist. Inside .buildout, we then create the directories eggs, downloads, and extends to store the various types of downloads, and a file called default.cfg, containing:

[buildout]
eggs-directory = /path/to/.buildout/eggs
download-cache = /path/to/.buildout/downloads
extends-cache  = /path/to/.buildout/extends

The default.cfg file can be used for other defaults if necessary. It behaves as if it is implicitly extended by any buildout you run.

Distributions using Setuptools/Distribute – include those we will write starting from Chapter 5, Developing a Site Strategy and use as develop eggs—consisting of a directory with a top-level setup.py file, and relevant source code, documentation, and other files.

setup.py contains metadata about the distribution itself, and declares its current version as well as any dependencies. Dependencies can be specified down to particular versions (such as ">=0.2,<1.0" means "later than version 0.2 but earlier than version 1.0"). Here is a sample setup.py file:

from setuptools import setup, find_packages
import os

version = '1.0'

setup(name='my.package',
      version=version,
      description="Description of my package",
      long_description=open("README.txt").read() + "\n" +
                   open(os.path.join("docs", "HISTORY.txt")).read(),
      author='Martin Aspeli',
      author_email='[email protected]',
      license='GPL',
      packages=find_packages(exclude=['ez_setup']),
      namespace_packages=['my'],
      include_package_data=True,
      zip_safe=False,
      install_requires=[
          'setuptools',
          'some.package >= 1.0',
      ],
      )

Here:

When a distribution is installed, Setuptools/Distribute will attempt to fulfill dependencies listed under install_requires by downloading and installing them if necessary. It will look for distributions on PyPI by default, but an alternative index can be specified if necessary, and secondary 'find-links' may be listed in the distribution itself.

It is possible to use setup.py to install a distribution into the global site packages of a given Python interpreter:

$ python setup.py install

To install a develop egg instead, we can run:

$ python setup.py develop

This creates a placeholder file that links to the distribution's source code, allowing it to be added to the Python path at runtime.

New packages can be released as source distributions, which are just zip files of the package with some additional metadata. We can build a source distribution of a package with:

$ python setup.py sdist

The new distribution will be placed in the dist subdirectory, which will be created if necessary.

Distributions can be uploaded to PyPI through a setup.py command:

$ python setup.py egg_info -RDb "" sdist register upload

You will be asked to specify or create a PyPI account if this is the first time you run this command. The login details are stored in the .pypirc file in your home directory.

The easy_install script searches PyPI or a similar index for distribution to download and install into the global Python environment. The latest valid versions of any dependencies will be included automatically. For example, we installed Virtualenv with:

$ easy_install -U virtualenv

Some distributions have optional dependencies known as extras. These can be installed using square bracket notation, for example:

$ easy_install -U my.package [someextra]

The same notation is supported in the install_requires line for dependencies. For example, a distribution that wanted to declare an extra called test that added a dependency on plone.testing with the z2 extra could add the following in its setup.py file:

      extras_require={
          'test': ['plone.testing[z2]',]
      },

Distributions can contain metadata about included plugins using a mechanism called entry points. This allows code to discover these plugins at runtime. Entry points are listed in setup.py, under the entry_points argument. For example, some Plone add-ons use an entry point like this to automatically register their configuration with Plone:

      entry_points="""
      [z3c.autoinclude.plugin]
      target = plone
      """,

Distributions using Setuptools/Distribute – include those we will write starting from Chapter 5, Developing a Site Strategy and use as develop eggs—consisting of a directory with a top-level setup.py file, and relevant source code, documentation, and other files.

setup.py contains metadata about the distribution itself, and declares its current version as well as any dependencies. Dependencies can be specified down to particular versions (such as ">=0.2,<1.0" means "later than version 0.2 but earlier than version 1.0"). Here is a sample setup.py file:

from setuptools import setup, find_packages
import os

version = '1.0'

setup(name='my.package',
      version=version,
      description="Description of my package",
      long_description=open("README.txt").read() + "\n" +
                   open(os.path.join("docs", "HISTORY.txt")).read(),
      author='Martin Aspeli',
      author_email='[email protected]',
      license='GPL',
      packages=find_packages(exclude=['ez_setup']),
      namespace_packages=['my'],
      include_package_data=True,
      zip_safe=False,
      install_requires=[
          'setuptools',
          'some.package >= 1.0',
      ],
      )

Here:

When a distribution is installed, Setuptools/Distribute will attempt to fulfill dependencies listed under install_requires by downloading and installing them if necessary. It will look for distributions on PyPI by default, but an alternative index can be specified if necessary, and secondary 'find-links' may be listed in the distribution itself.

It is possible to use setup.py to install a distribution into the global site packages of a given Python interpreter:

$ python setup.py install

To install a develop egg instead, we can run:

$ python setup.py develop

This creates a placeholder file that links to the distribution's source code, allowing it to be added to the Python path at runtime.

New packages can be released as source distributions, which are just zip files of the package with some additional metadata. We can build a source distribution of a package with:

$ python setup.py sdist

The new distribution will be placed in the dist subdirectory, which will be created if necessary.

Distributions can be uploaded to PyPI through a setup.py command:

$ python setup.py egg_info -RDb "" sdist register upload

You will be asked to specify or create a PyPI account if this is the first time you run this command. The login details are stored in the .pypirc file in your home directory.

The easy_install script searches PyPI or a similar index for distribution to download and install into the global Python environment. The latest valid versions of any dependencies will be included automatically. For example, we installed Virtualenv with:

$ easy_install -U virtualenv

Some distributions have optional dependencies known as extras. These can be installed using square bracket notation, for example:

$ easy_install -U my.package [someextra]

The same notation is supported in the install_requires line for dependencies. For example, a distribution that wanted to declare an extra called test that added a dependency on plone.testing with the z2 extra could add the following in its setup.py file:

      extras_require={
          'test': ['plone.testing[z2]',]
      },

Distributions can contain metadata about included plugins using a mechanism called entry points. This allows code to discover these plugins at runtime. Entry points are listed in setup.py, under the entry_points argument. For example, some Plone add-ons use an entry point like this to automatically register their configuration with Plone:

      entry_points="""
      [z3c.autoinclude.plugin]
      target = plone
      """,

Let us now examine the various development tools that we will use throughout the book.

[sources]
my.package = svn https://svn.example.org/repos/my.package/trunk
my.otherpackage = git https://github.com/myorg/my.otherpackage

[sources]
optilux.policy = fs optilux.policy

[buildout]
...
auto-checkout =
    my.package
    my.otherpackage

*************** PICKED VERSIONS ****************
[versions]
Products.PDBDebugMode = 1.1
Products.PrintingMailHost = 0.7
*************** /PICKED VERSIONS ***************

For development, we usually use a single Zope instance, controlled by the script bin/instance (the script name is taken from the part name in the buildout configuration), with a local Data.fs file and blobstorage directory containing the Zope database. This instance is optimized for use in a development environment, and has the verbose-security flag turned on, to give more details about security-related errors.

During development, we normally run Zope in foreground mode, with:

$ bin/instance fg

Not only does this make it easier to see log messages and use the debugger, it also ensures that Zope runs in debug mode, which, among other things, ensures that page templates on the filesystem can be modified and their changes take effect without restarting Zope, and disables caching and merging of Plone's CSS and JavaScript resources.

We also install various development tools into the Zope instance. These are outlined in the subsequent sections.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Let us now examine the various development tools that we will use throughout the book.

[sources]
my.package = svn https://svn.example.org/repos/my.package/trunk
my.otherpackage = git https://github.com/myorg/my.otherpackage

[sources]
optilux.policy = fs optilux.policy

[buildout]
...
auto-checkout =
    my.package
    my.otherpackage

*************** PICKED VERSIONS ****************
[versions]
Products.PDBDebugMode = 1.1
Products.PrintingMailHost = 0.7
*************** /PICKED VERSIONS ***************

For development, we usually use a single Zope instance, controlled by the script bin/instance (the script name is taken from the part name in the buildout configuration), with a local Data.fs file and blobstorage directory containing the Zope database. This instance is optimized for use in a development environment, and has the verbose-security flag turned on, to give more details about security-related errors.

During development, we normally run Zope in foreground mode, with:

$ bin/instance fg

Not only does this make it easier to see log messages and use the debugger, it also ensures that Zope runs in debug mode, which, among other things, ensures that page templates on the filesystem can be modified and their changes take effect without restarting Zope, and disables caching and merging of Plone's CSS and JavaScript resources.

We also install various development tools into the Zope instance. These are outlined in the subsequent sections.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

For development, we usually use a single Zope instance, controlled by the script bin/instance (the script name is taken from the part name in the buildout configuration), with a local Data.fs file and blobstorage directory containing the Zope database. This instance is optimized for use in a development environment, and has the verbose-security flag turned on, to give more details about security-related errors.

During development, we normally run Zope in foreground mode, with:

$ bin/instance fg

Not only does this make it easier to see log messages and use the debugger, it also ensures that Zope runs in debug mode, which, among other things, ensures that page templates on the filesystem can be modified and their changes take effect without restarting Zope, and disables caching and merging of Plone's CSS and JavaScript resources.

We also install various development tools into the Zope instance. These are outlined in the subsequent sections.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

For development, we usually use a single Zope instance, controlled by the script bin/instance (the script name is taken from the part name in the buildout configuration), with a local Data.fs file and blobstorage directory containing the Zope database. This instance is optimized for use in a development environment, and has the verbose-security flag turned on, to give more details about security-related errors.

During development, we normally run Zope in foreground mode, with:

$ bin/instance fg

Not only does this make it easier to see log messages and use the debugger, it also ensures that Zope runs in debug mode, which, among other things, ensures that page templates on the filesystem can be modified and their changes take effect without restarting Zope, and disables caching and merging of Plone's CSS and JavaScript resources.

We also install various development tools into the Zope instance. These are outlined in the subsequent sections.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

For development, we usually use a single Zope instance, controlled by the script bin/instance (the script name is taken from the part name in the buildout configuration), with a local Data.fs file and blobstorage directory containing the Zope database. This instance is optimized for use in a development environment, and has the verbose-security flag turned on, to give more details about security-related errors.

During development, we normally run Zope in foreground mode, with:

$ bin/instance fg

Not only does this make it easier to see log messages and use the debugger, it also ensures that Zope runs in debug mode, which, among other things, ensures that page templates on the filesystem can be modified and their changes take effect without restarting Zope, and disables caching and merging of Plone's CSS and JavaScript resources.

We also install various development tools into the Zope instance. These are outlined in the subsequent sections.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

For development, we usually use a single Zope instance, controlled by the script bin/instance (the script name is taken from the part name in the buildout configuration), with a local Data.fs file and blobstorage directory containing the Zope database. This instance is optimized for use in a development environment, and has the verbose-security flag turned on, to give more details about security-related errors.

During development, we normally run Zope in foreground mode, with:

$ bin/instance fg

Not only does this make it easier to see log messages and use the debugger, it also ensures that Zope runs in debug mode, which, among other things, ensures that page templates on the filesystem can be modified and their changes take effect without restarting Zope, and disables caching and merging of Plone's CSS and JavaScript resources.

We also install various development tools into the Zope instance. These are outlined in the subsequent sections.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Throughout this book, we will be writing automated tests for our code. To run those tests, we need a test runner, which is installed with zc.recipe.testrunner.

This recipe takes an eggs option, under which we list every distribution we want to test. In our buildout, this is initialized from ${eggs:test} from packages.cfg.

The test runner recipe generates a script called bin/test (the name is taken from the test runner part's section). To run all tests, simply do:

$ bin/test

To run only the tests in a particular package, use the -s option:

$ bin/test -s my.package

To run only a test with a name matching a particular regular expression, use the -t option:

$ bin/test -s my.package -t test_something

See the output of bin/test --help for other options.

$ bin/test --coverage=coverage

$ bin/coverage

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

It is useful to be able to search the 'active' source code for debugging and analysis purposes. With numerous distributions making up the Plone working set, however, it can be difficult to keep track of which packages are currently in use.

To make this easier, we can use collective.recipe.omelette. This presents a single 'virtual' source tree of the current working set by creating symbolic links to all packages in all (unzipped) eggs in the directory parts/omelette.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Python lets us quickly prototype code on the interactive interpreter prompt. This is very powerful and can save much guessing. To be able to import Zope and Plone code, however, we need the relevant set of packages available. This is achieved with the bin/zopepy script, which is simply a Python interpreter with the correct sys.path mangling applied.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

ZopeSkel is a collection of skeleton templates that can be used to create new distributions quickly. It is installed as bin/zopeskel. We will see how to use this in Chapter 5, Developing a Site Strategy, but in the meantime, you can run bin/zopeskel --help to learn how to use it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

We have extolled the virtues of pinning distributions a few times already, but one downside of maintaining version pins is that discovering new releases requires manually checking PyPI or other sources. For major components with their own known good version sets such as Plone, this is not so much of an issue, but for our various development tools and third-party dependencies, it can become a hassle.

To help with this, we can use the bin/checkversions script installed by z3c.checkversions. To run it against our versions.cfg file, we would do:

$ bin/checkversions versions.cfg

This will report the latest available version on PyPI. If we are only interested in bug fixes, we can restrict the check to minor versions, with:

$ bin/checkversions versions.cfg --level=2

See the output of bin/checkversions --help for more options.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Eventually, we will need to make releases of our distributions. For distributions we intend to release to the public that can mean uploading source distributions to PyPI. For internal distributions, we usually want to release to an internal distribution location, so that we have immutable, versioned distributions for deployment.

As we will show in the final part of this book, we can use bin/mkrelease, installed by jarn.mkrelease, to easily make releases. For more information, see http://pypi.python.org/pypi/jarn.mkrelease.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

The humble web browser is an important part of our development environment. Not only does it allow us to manually test our site; modern browsers also come with development tools that allow us to debug JavaScript, understand what CSS is affecting what elements on the page, prototype JavaScript code, and CSS changes, inspect request and response headers, and inspect and modify the HTML structure on the fly.

Chrome and Safari both have built-in development tools. For Firefox, there is the ever popular Firebug. Get it from http://getfirebug.com, and wonder how you ever lived without it.

Documentation for Plone code can usually be found in one of the following places:

Python's readability is both a blessing and a curse. A blessing because it is normally possible to read the source code to find out what is going on. A curse because this sometimes makes developers a little lax about documentation.

One of the first hurdles new developers should overcome is any undue respect for the Python files that make up Zope and Plone. There is (almost) nothing magical about them. Earlier, we showed how to install an 'omelette' (in the parts/omelette directory inside the buildout root) that provides a single view of the source code that makes up the Plone runtime environment for a project. This is the best place to look for source code.

Get used to searching for code using grep or equivalent graphical tools, opening them and looking for specific classes and methods. Seeing what a piece of code does can often be faster than looking up documentation or examples. As time goes by, you will find that a few packages come up repeatedly, and finding code will be easier.

You can of course change these files as well. A backup is advisable, but if you think that temporarily raising an exception, adding a PDB break point, or printing a message from somewhere deep inside Zope helps you to solve a problem, go right ahead.

PDB, the Python debugger, is your best friend. To insert a breakpoint in your code or in some other code that you are trying to debug add the following line and (re-)start Zope in the foreground in a terminal:

import pdb; pdb.set_trace()

When this line is encountered, execution will stop, and the terminal will display:

(pdb)

This is the interactive PDB prompt. Type help and press Enter to see available commands. The most important ones are pp, to print a variable or the result of an expression; n to step to the next line; s to step into a function call; l to show a listing of the source code around the current execution point; tbreak to add a temporary breakpoint at a particular line, and c, to stop debugging and continue execution until another breakpoint is encountered.

If you want to quickly test syntax or libraries, you can run Python's interactive interpreter, through the bin/zopepy script as described earlier.

During development, you should typically run Plone in a terminal window, using bin/instance fg. This enables debug mode and prints log messages to the console. If anything goes wrong, you should inspect the log first.

If an exception is encountered, you will likely see a traceback. For example:

Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module Products.CMFPlone.FactoryTool, line 361, in __call__
Module Products.CMFPlone.FactoryTool, line 147, in __getitem__
Module Products.CMFPlone.PloneFolder, line 406, in invokeFactory
Module Products.CMFCore.TypesTool, line 934, in constructContent
Module Products.CMFCore.TypesTool, line 345, in constructInstance
Module Products.CMFCore.TypesTool, line 357, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 145, in notifyWorkflowCreated
Module Products.CMFCore.WorkflowTool, line 355, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 392, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 476, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 571, in _executeTransition
Module Products.DCWorkflow.DCWorkflow, line 435, in updateRoleMappingsFor
Module Products.DCWorkflow.utils, line 60, in modifyRolesForPermission
Module AccessControl.Permission, line 93, in setRoles
AttributeError: appname

The actual error is usually on the last line of the traceback. If this is not in any code that you wrote, chances are something you did further up the stack caused the problem, if you passed an invalid argument to a function. Start from the end and work your way up the stack trace until you see some code that you wrote, and start debugging from there.

Documentation for Plone code can usually be found in one of the following places:

Python's readability is both a blessing and a curse. A blessing because it is normally possible to read the source code to find out what is going on. A curse because this sometimes makes developers a little lax about documentation.

One of the first hurdles new developers should overcome is any undue respect for the Python files that make up Zope and Plone. There is (almost) nothing magical about them. Earlier, we showed how to install an 'omelette' (in the parts/omelette directory inside the buildout root) that provides a single view of the source code that makes up the Plone runtime environment for a project. This is the best place to look for source code.

Get used to searching for code using grep or equivalent graphical tools, opening them and looking for specific classes and methods. Seeing what a piece of code does can often be faster than looking up documentation or examples. As time goes by, you will find that a few packages come up repeatedly, and finding code will be easier.

You can of course change these files as well. A backup is advisable, but if you think that temporarily raising an exception, adding a PDB break point, or printing a message from somewhere deep inside Zope helps you to solve a problem, go right ahead.

PDB, the Python debugger, is your best friend. To insert a breakpoint in your code or in some other code that you are trying to debug add the following line and (re-)start Zope in the foreground in a terminal:

import pdb; pdb.set_trace()

When this line is encountered, execution will stop, and the terminal will display:

(pdb)

This is the interactive PDB prompt. Type help and press Enter to see available commands. The most important ones are pp, to print a variable or the result of an expression; n to step to the next line; s to step into a function call; l to show a listing of the source code around the current execution point; tbreak to add a temporary breakpoint at a particular line, and c, to stop debugging and continue execution until another breakpoint is encountered.

If you want to quickly test syntax or libraries, you can run Python's interactive interpreter, through the bin/zopepy script as described earlier.

During development, you should typically run Plone in a terminal window, using bin/instance fg. This enables debug mode and prints log messages to the console. If anything goes wrong, you should inspect the log first.

If an exception is encountered, you will likely see a traceback. For example:

Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module Products.CMFPlone.FactoryTool, line 361, in __call__
Module Products.CMFPlone.FactoryTool, line 147, in __getitem__
Module Products.CMFPlone.PloneFolder, line 406, in invokeFactory
Module Products.CMFCore.TypesTool, line 934, in constructContent
Module Products.CMFCore.TypesTool, line 345, in constructInstance
Module Products.CMFCore.TypesTool, line 357, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 145, in notifyWorkflowCreated
Module Products.CMFCore.WorkflowTool, line 355, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 392, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 476, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 571, in _executeTransition
Module Products.DCWorkflow.DCWorkflow, line 435, in updateRoleMappingsFor
Module Products.DCWorkflow.utils, line 60, in modifyRolesForPermission
Module AccessControl.Permission, line 93, in setRoles
AttributeError: appname

The actual error is usually on the last line of the traceback. If this is not in any code that you wrote, chances are something you did further up the stack caused the problem, if you passed an invalid argument to a function. Start from the end and work your way up the stack trace until you see some code that you wrote, and start debugging from there.

Python's readability is both a blessing and a curse. A blessing because it is normally possible to read the source code to find out what is going on. A curse because this sometimes makes developers a little lax about documentation.

One of the first hurdles new developers should overcome is any undue respect for the Python files that make up Zope and Plone. There is (almost) nothing magical about them. Earlier, we showed how to install an 'omelette' (in the parts/omelette directory inside the buildout root) that provides a single view of the source code that makes up the Plone runtime environment for a project. This is the best place to look for source code.

Get used to searching for code using grep or equivalent graphical tools, opening them and looking for specific classes and methods. Seeing what a piece of code does can often be faster than looking up documentation or examples. As time goes by, you will find that a few packages come up repeatedly, and finding code will be easier.

You can of course change these files as well. A backup is advisable, but if you think that temporarily raising an exception, adding a PDB break point, or printing a message from somewhere deep inside Zope helps you to solve a problem, go right ahead.

PDB, the Python debugger, is your best friend. To insert a breakpoint in your code or in some other code that you are trying to debug add the following line and (re-)start Zope in the foreground in a terminal:

import pdb; pdb.set_trace()

When this line is encountered, execution will stop, and the terminal will display:

(pdb)

This is the interactive PDB prompt. Type help and press Enter to see available commands. The most important ones are pp, to print a variable or the result of an expression; n to step to the next line; s to step into a function call; l to show a listing of the source code around the current execution point; tbreak to add a temporary breakpoint at a particular line, and c, to stop debugging and continue execution until another breakpoint is encountered.

If you want to quickly test syntax or libraries, you can run Python's interactive interpreter, through the bin/zopepy script as described earlier.

During development, you should typically run Plone in a terminal window, using bin/instance fg. This enables debug mode and prints log messages to the console. If anything goes wrong, you should inspect the log first.

If an exception is encountered, you will likely see a traceback. For example:

Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module Products.CMFPlone.FactoryTool, line 361, in __call__
Module Products.CMFPlone.FactoryTool, line 147, in __getitem__
Module Products.CMFPlone.PloneFolder, line 406, in invokeFactory
Module Products.CMFCore.TypesTool, line 934, in constructContent
Module Products.CMFCore.TypesTool, line 345, in constructInstance
Module Products.CMFCore.TypesTool, line 357, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 145, in notifyWorkflowCreated
Module Products.CMFCore.WorkflowTool, line 355, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 392, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 476, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 571, in _executeTransition
Module Products.DCWorkflow.DCWorkflow, line 435, in updateRoleMappingsFor
Module Products.DCWorkflow.utils, line 60, in modifyRolesForPermission
Module AccessControl.Permission, line 93, in setRoles
AttributeError: appname

The actual error is usually on the last line of the traceback. If this is not in any code that you wrote, chances are something you did further up the stack caused the problem, if you passed an invalid argument to a function. Start from the end and work your way up the stack trace until you see some code that you wrote, and start debugging from there.

PDB, the Python debugger, is your best friend. To insert a breakpoint in your code or in some other code that you are trying to debug add the following line and (re-)start Zope in the foreground in a terminal:

import pdb; pdb.set_trace()

When this line is encountered, execution will stop, and the terminal will display:

(pdb)

This is the interactive PDB prompt. Type help and press Enter to see available commands. The most important ones are pp, to print a variable or the result of an expression; n to step to the next line; s to step into a function call; l to show a listing of the source code around the current execution point; tbreak to add a temporary breakpoint at a particular line, and c, to stop debugging and continue execution until another breakpoint is encountered.

If you want to quickly test syntax or libraries, you can run Python's interactive interpreter, through the bin/zopepy script as described earlier.

During development, you should typically run Plone in a terminal window, using bin/instance fg. This enables debug mode and prints log messages to the console. If anything goes wrong, you should inspect the log first.

If an exception is encountered, you will likely see a traceback. For example:

Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module Products.CMFPlone.FactoryTool, line 361, in __call__
Module Products.CMFPlone.FactoryTool, line 147, in __getitem__
Module Products.CMFPlone.PloneFolder, line 406, in invokeFactory
Module Products.CMFCore.TypesTool, line 934, in constructContent
Module Products.CMFCore.TypesTool, line 345, in constructInstance
Module Products.CMFCore.TypesTool, line 357, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 145, in notifyWorkflowCreated
Module Products.CMFCore.WorkflowTool, line 355, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 392, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 476, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 571, in _executeTransition
Module Products.DCWorkflow.DCWorkflow, line 435, in updateRoleMappingsFor
Module Products.DCWorkflow.utils, line 60, in modifyRolesForPermission
Module AccessControl.Permission, line 93, in setRoles
AttributeError: appname

The actual error is usually on the last line of the traceback. If this is not in any code that you wrote, chances are something you did further up the stack caused the problem, if you passed an invalid argument to a function. Start from the end and work your way up the stack trace until you see some code that you wrote, and start debugging from there.

During development, you should typically run Plone in a terminal window, using bin/instance fg. This enables debug mode and prints log messages to the console. If anything goes wrong, you should inspect the log first.

If an exception is encountered, you will likely see a traceback. For example:

Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module Products.CMFPlone.FactoryTool, line 361, in __call__
Module Products.CMFPlone.FactoryTool, line 147, in __getitem__
Module Products.CMFPlone.PloneFolder, line 406, in invokeFactory
Module Products.CMFCore.TypesTool, line 934, in constructContent
Module Products.CMFCore.TypesTool, line 345, in constructInstance
Module Products.CMFCore.TypesTool, line 357, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 145, in notifyWorkflowCreated
Module Products.CMFCore.WorkflowTool, line 355, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 392, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 476, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 571, in _executeTransition
Module Products.DCWorkflow.DCWorkflow, line 435, in updateRoleMappingsFor
Module Products.DCWorkflow.utils, line 60, in modifyRolesForPermission
Module AccessControl.Permission, line 93, in setRoles
AttributeError: appname

The actual error is usually on the last line of the traceback. If this is not in any code that you wrote, chances are something you did further up the stack caused the problem, if you passed an invalid argument to a function. Start from the end and work your way up the stack trace until you see some code that you wrote, and start debugging from there.