zope.app.appsetup README
========================
This package provides application setup helpers for the Zope3 appserver.
.. contents::
Bootstrap helpers
=================
The bootstrap helpers provide a number of functions that help with
bootstrapping.
The bootStrapSubscriber function makes sure that there is a root
object. It subscribes to DatabaseOpened events:
>>> from zope.app.appsetup import bootstrap
>>> import zope.processlifetime
>>> from ZODB.MappingStorage import DB
>>> db = DB()
>>> bootstrap.bootStrapSubscriber(zope.processlifetime.DatabaseOpened(db))
The subscriber makes sure that there is a root folder:
>>> from zope.app.publication.zopepublication import ZopePublication
>>> conn = db.open()
>>> root = conn.root()[ZopePublication.root_name]
>>> sm = root.getSiteManager()
>>> conn.close()
A DatabaseOpenedWithRoot is generated with the database.
>>> from zope.component.eventtesting import getEvents
>>> [event] = getEvents(zope.processlifetime.IDatabaseOpenedWithRoot)
>>> event.database is db
True
Generally, startup code that expects the root object and site to have
been created will want to subscribe to this event, not
IDataBaseOpenedEvent.
The subscriber generates the event whether or not the root had to be
set up:
>>> bootstrap.bootStrapSubscriber(zope.processlifetime.DatabaseOpened(db))
>>> [e, event] = getEvents(zope.processlifetime.IDatabaseOpenedWithRoot)
>>> event.database is db
True
Check the Security Policy
-------------------------
When the security policy got refactored to be really pluggable, the
inclusion of the security policy configuration was moved to the very
top level, to site.zcml. This happened in r24770, after ZopeX3 3.0
was released, but before 3.1.
Now the maintainers of existing 3.0 sites need to manually update
their site.zcml to include securitypolicy.zcml while upgrading to 3.1.
See also http://www.zope.org/Collectors/Zope3-dev/381 .
>>> from zope.testing.loggingsupport import InstalledHandler
>>> handler = InstalledHandler('zope.app.appsetup')
If the security policy is unset from the default
ParanoidSecurityPolicy, we get a warning:
>>> from zope.app.appsetup.bootstrap import checkSecurityPolicy
>>> event = object()
>>> checkSecurityPolicy(event)
>>> print(handler)
zope.app.appsetup WARNING
Security policy is not configured.
Please make sure that securitypolicy.zcml is included in site.zcml immediately
before principals.zcml
However, if any non-default security policy is installed, no warning
is emitted:
>>> from zope.security.management import setSecurityPolicy
>>> defaultPolicy = setSecurityPolicy(object())
>>> handler.clear()
>>> checkSecurityPolicy(event)
>>> print(handler)
<BLANKLINE>
Clean up:
>>> handler.uninstall()
Debug console
=============
The debug console lets you have a Python prompt with the full Zope
environment loaded (which includes the ZCML configuration, as well as an open
database connection).
Let's define a helper to run the debug script and trap SystemExit exceptions
that would otherwise hide the output
>>> from __future__ import print_function
>>> import sys
>>> from zope.app.appsetup import debug
>>> def run(*args):
... sys.argv[0] = 'debug'
... sys.stderr = sys.stdout
... try:
... debug.main(args)
... except SystemExit as e:
... print("(exited with status %d)" % e.code)
If you call the script with no arguments, it displays a brief error message
on stderr
>>> run()
Error: please specify a configuration file
For help, use debug -h
(exited with status 2)
We need to pass a ZConfig configuration file as an argument
>>> run('-C', 'test.conf.txt')
The application root is known as `root`.
Now you have the root object from the open database available as a global
variable named 'root' in the __main__ module:
>>> main_module = sys.modules['__main__']
>>> main_module.root # doctest: +ELLIPSIS
<zope.site.folder.Folder object at ...>
and we have asked Python to enter interactive mode by setting the
PYTHONINSPECT environment variable
>>> import os
>>> os.environ.get('PYTHONINSPECT')
'true'
We have to do extra work to honor the PYTHONSTARTUP environment variable:
>>> pythonstartup = os.path.join(os.path.dirname(debug.__file__),
... 'testdata', 'pythonstartup.py')
>>> os.environ['PYTHONSTARTUP'] = pythonstartup
>>> run('-C', 'test.conf.txt')
The application root is known as `root`.
You can see that our pythonstartup file was executed because it changed
the prompt
>>> sys.ps1
'debug> '
Product-specific configuration
==============================
The ``product`` module of this package provides a very simple way to deal with
what has traditionally been called "product configuration", where "product"
refers to the classic Zope 2 notion of a product.
The configuration schema for the application server allows named
<product-config> sections to be added to the configuration file, and product
code can use the API provided by the module to retrieve configuration sections
for given names.
There are two public functions in the module that should be used in normal
operations, and additional functions and a class that can be used to help with
testing:
>>> from __future__ import print_function
>>> from zope.app.appsetup import product
Let's look at the helper class first, since we'll use it in describing the
public (application) interface. We'll follow that with the functions for
normal operation, then the remaining test-support functions.
Faux configuration object
-------------------------
The ``FauxConfiguration`` class constructs objects that behave like the
ZConfig section objects to the extent needed for the product configuration
API. These will be used here, and may also be used to create configurations
for testing components that consume such configuration.
The constructor requires two arguments: the name of the section, and a mapping
of keys to values that the section should provide. Let's create a simple
example:
>>> one = product.FauxConfiguration("one", {})
>>> one.getSectionName()
'one'
>>> one.mapping
{}
Providing a non-empty set of key/value pairs trivially behaves as expected:
>>> two = product.FauxConfiguration("two", {"abc": "def"})
>>> two.getSectionName()
'two'
>>> two.mapping
{'abc': 'def'}
Application API
---------------
There are two functions in the application interface for this module. One is
used by the configuration provider, and the other is used by the consumer.
The provider's API takes a sequence of configuration objects that conform to
the behaviors exhibited by the default ZConfig section objects. Since the
``FauxConfiguration`` class provides these behaviors, we can easily see how
this can be used:
>>> product.setProductConfigurations([one, two])
Now that we've established some configuration, we want to be able to use it.
We do this using the ``getProductConfiguration()`` function. This function
takes a name and returns a matching configuration section if there is one, of
None if not:
>>> product.getProductConfiguration("one")
{}
>>> product.getProductConfiguration("not-there") is None
True
Note that for a section that exists, only the internal mapping is provided,
not the containing section object. This is a historical wart; we'll just need
to live with it until new APIs are introduced.
Setting the configuration a second time will overwrite the prior
configuration; sections previously available will no longer be:
>>> product.setProductConfigurations([two])
>>> product.getProductConfiguration("one") is None
True
The new sections are available, as expected:
>>> product.getProductConfiguration("two")
{'abc': 'def'}
Test support functions
----------------------
Additional functions are provided that make it easier to manage configuration
state in testing.
The first can be used to provide configuration for a single name. The
function takes a name and either a configuration mapping or ``None`` as
arguments. If ``None`` is provided as the second argument, any configuration
settings for the name are removed, if present. If the second argument is not
``None``, it will be used as the return value for ``getProductConfiguration``
for the given name.
>>> product.setProductConfiguration("first", None)
>>> print(product.getProductConfiguration("first"))
None
>>> product.setProductConfiguration("first", {"key": "value1"})
>>> product.getProductConfiguration("first")
{'key': 'value1'}
>>> product.setProductConfiguration("first", {"key": "value2"})
>>> product.getProductConfiguration("first")
{'key': 'value2'}
>>> product.setProductConfiguration("first", {"alt": "another"})
>>> product.getProductConfiguration("first")
{'alt': 'another'}
>>> product.setProductConfiguration("second", {"you": "there"})
>>> product.getProductConfiguration("first")
{'alt': 'another'}
>>> product.getProductConfiguration("second")
{'you': 'there'}
>>> product.setProductConfiguration("first", None)
>>> print(product.getProductConfiguration("first"))
None
The other two functions work in concert, saving and restoring the entirety of
the configuration state.
Our current configuration includes data for the "second" key, and none for the
"first" key:
>>> print(product.getProductConfiguration("first"))
None
>>> print(product.getProductConfiguration("second"))
{'you': 'there'}
Let's save this state:
>>> state = product.saveConfiguration()
Now let's replace the kitchen sink:
>>> product.setProductConfigurations([
... product.FauxConfiguration("x", {"a": "b"}),
... product.FauxConfiguration("y", {"c": "d"}),
... ])
>>> print(product.getProductConfiguration("first"))
None
>>> print(product.getProductConfiguration("second"))
None
>>> product.getProductConfiguration("x")
{'a': 'b'}
>>> product.getProductConfiguration("y")
{'c': 'd'}
The saved configuration state can be restored:
>>> product.restoreConfiguration(state)
>>> print(product.getProductConfiguration("x"))
None
>>> print(product.getProductConfiguration("y"))
None
>>> print(product.getProductConfiguration("first"))
None
>>> print(product.getProductConfiguration("second"))
{'you': 'there'}
There's an additional function that can be used to load product configuration
from a file object; only product configuration components are accepted. The
function returns a mapping of names to configuration objects suitable for
passing to ``setProductConfiguration``. Using this with
``setProductConfigurations`` would require constructing ``FauxConfiguration``
objects.
Let's create some sample configuration text:
>>> product_config = '''
... <product-config product1>
... key1 product1-value1
... key2 product1-value2
... </product-config>
...
... <product-config product2>
... key1 product2-value1
... key3 product2-value2
... </product-config>
... '''
We can now load the configuration using the ``loadConfiguration`` function:
>>> import io
>>> import pprint
>>> sio = io.StringIO(product_config)
>>> config = product.loadConfiguration(sio)
>>> pprint.pprint(config, width=1)
{'product1': {'key1': 'product1-value1',
'key2': 'product1-value2'},
'product2': {'key1': 'product2-value1',
'key3': 'product2-value2'}}
Extensions that provide product configurations can be used as well:
>>> product_config = '''
... %import zope.app.appsetup.testproduct
...
... <testproduct foobar>
... </testproduct>
...
... <testproduct barfoo>
... key1 value1
... key2 value2
... </testproduct>
... '''
>>> sio = io.StringIO(product_config)
>>> config = product.loadConfiguration(sio)
>>> pprint.pprint(config, width=1)
{'barfoo': {'key1': 'value1',
'key2': 'value2',
'product-name': 'barfoo'},
'foobar': {'product-name': 'foobar'}}
Changelog
=========
5.0 (2023-02-09)
----------------
- Add support for Python 3.9, 3.10, 3.11.
- Drop support for Python 2.7, 3.5, 3.6.
4.2.0 (2020-05-20)
------------------
- Drop support for ``python setup.py test``.
- Add support for Python 3.8.
- Drop support for Python 3.4.
4.1.0 (2018-12-15)
------------------
- Add support for Python 3.6, 3.7 and PyPy3.
- Drop support for Python 3.3.
4.0.0 (2016-08-08)
------------------
- Add dependency on ``zdaemon`` (split off from ``ZODB``).
- Claim support for Python 3.4, 3.5 and PyPy which requires
``zope.app.publication`` >= 4.0.
- Drop Python 2.6 support.
4.0.0a1 (2013-03-03)
--------------------
- Added support for Python 3.3.
- Replaced deprecated ``zope.interface.implements`` usage with equivalent
``zope.interface.implementer`` decorator.
- Dropped support for Python 2.4 and 2.5.
3.16.0 (2011-01-27)
-------------------
- Added stacking of storages for layer/test level setup separation in derived
ZODBLayers.
3.15.0 (2010-09-25)
-------------------
- Updated tests to run with `zope.testing >= 3.10`, requiring at least this
version and `zope.testrunner`.
- Switch ``IErrorReportingUtility copy_to_zlog`` field to ``True``.
- Using Python's `doctest` module instead of depreacted
`zope.testing.doctest`.
3.14.0 (2010-04-13)
-------------------
- Made `zope.testing` an optional (test) dependency.
- Removed test dependency on `zope.app.testing`.
3.13.0 (2009-12-24)
-------------------
- Import hooks functionality from zope.component after it was moved there from
zope.site.
- Import ISite from zope.component after it was moved there from
zope.location. This lifts the dependency on zope.location.
- Added missing install dependency on `zope.testing`.
3.12.0 (2009-06-20)
-------------------
- Using ``zope.processlifetime`` interfaces and implementations
directly instead of BBB imports from ``zope.app.appsetup``.
- Got rid of depencency on ``zope.app.component``.
- Got rid of test dependency on ``zope.app.security``.
3.11 (2009-05-13)
-----------------
- Event interfaces / implementations moved to ``zope.processlifetime``,
version 1.0. Depend on this package, and add BBB imports.
3.10.1 (2009-03-31)
-------------------
- Fixed a ``DeprecationWarning`` introduced in 3.10.0.
- Added doctests to long description to show up at pypi.
3.10.0 (2009-03-19)
-------------------
- Finally deprecate the "asObject" argument of helper functions in the
``zope.app.appsetup.bootstrap`` module. If your code uses any of these
functions, please remove the "asObject=True" argument passing anywhere,
because the support for that argument will be dropped soon.
- Move session utility bootstrapping logic from ``zope.session`` into this
package. This removes a dependency from zope.session to this package.
- Remove one more deprecated function.
3.9.0 (2009-01-31)
------------------
- Use ``zope.site`` instead of ``zope.app.folder`` and
``zope.app.component``.
- Use ``zope.container`` instead of ``zope.app.container``.
- Move error log bootstrapping logic from ``zope.error`` into this
package. This removes a dependency from zope.error to this
package. Also added a test for bootstrapping the error log here,
which was missing in ``zope.error``.
3.8.0 (2008-08-25)
------------------
- Feature: Developed an entry point that allows you to quickly bring up an
application instance for debugging purposes. (Implemented by Marius Gedminas
and Stephan Richter.)
3.7.0 (2008-08-19)
------------------
- Added ``.product.loadConfiguration`` test-support function; loads product
configuration (only) from a file object, allowing test code (including
setup) to make use of the same configuration schema support used by normal
startup.
3.6.0 (2008-07-23)
------------------
- Added additional test support functions to set the configuration for a
single section, and save/restore the entire configuration.
3.5.0 (2008-06-17)
------------------
- Added helper class for supporting product configuration tests.
- Added documentation for the product configuration API, with tests.
3.4.1 (2007-09-27)
------------------
- Egg was faulty, re-released.
3.4.0 (2007-09-25)
------------------
- Initial documented release.
- Reflect changes form zope.app.error refactoring.
Raw data
{
"_id": null,
"home_page": "https://github.com/zopefoundation/zope.app.appsetup",
"name": "zope.app.appsetup",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.7",
"maintainer_email": "",
"keywords": "zope3 app setup",
"author": "Zope Corporation and Contributors",
"author_email": "zope-dev@zope.dev",
"download_url": "https://files.pythonhosted.org/packages/83/b8/20dd498f46973f3ca448971574700619f35fbfc18d82d20be807392752d4/zope.app.appsetup-5.0.tar.gz",
"platform": null,
"description": "zope.app.appsetup README\n========================\n\nThis package provides application setup helpers for the Zope3 appserver.\n\n\n.. contents::\n\nBootstrap helpers\n=================\n\nThe bootstrap helpers provide a number of functions that help with\nbootstrapping.\n\nThe bootStrapSubscriber function makes sure that there is a root\nobject. It subscribes to DatabaseOpened events:\n\n >>> from zope.app.appsetup import bootstrap\n >>> import zope.processlifetime\n\n >>> from ZODB.MappingStorage import DB\n >>> db = DB()\n >>> bootstrap.bootStrapSubscriber(zope.processlifetime.DatabaseOpened(db))\n\nThe subscriber makes sure that there is a root folder:\n\n >>> from zope.app.publication.zopepublication import ZopePublication\n >>> conn = db.open()\n >>> root = conn.root()[ZopePublication.root_name]\n >>> sm = root.getSiteManager()\n >>> conn.close()\n\nA DatabaseOpenedWithRoot is generated with the database.\n\n >>> from zope.component.eventtesting import getEvents\n >>> [event] = getEvents(zope.processlifetime.IDatabaseOpenedWithRoot)\n >>> event.database is db\n True\n\nGenerally, startup code that expects the root object and site to have\nbeen created will want to subscribe to this event, not\nIDataBaseOpenedEvent.\n\nThe subscriber generates the event whether or not the root had to be\nset up:\n\n >>> bootstrap.bootStrapSubscriber(zope.processlifetime.DatabaseOpened(db))\n >>> [e, event] = getEvents(zope.processlifetime.IDatabaseOpenedWithRoot)\n >>> event.database is db\n True\n\n\nCheck the Security Policy\n-------------------------\n\nWhen the security policy got refactored to be really pluggable, the\ninclusion of the security policy configuration was moved to the very\ntop level, to site.zcml. This happened in r24770, after ZopeX3 3.0\nwas released, but before 3.1.\n\nNow the maintainers of existing 3.0 sites need to manually update\ntheir site.zcml to include securitypolicy.zcml while upgrading to 3.1.\nSee also http://www.zope.org/Collectors/Zope3-dev/381 .\n\n >>> from zope.testing.loggingsupport import InstalledHandler\n >>> handler = InstalledHandler('zope.app.appsetup')\n\nIf the security policy is unset from the default\nParanoidSecurityPolicy, we get a warning:\n\n >>> from zope.app.appsetup.bootstrap import checkSecurityPolicy\n >>> event = object()\n >>> checkSecurityPolicy(event)\n >>> print(handler)\n zope.app.appsetup WARNING\n Security policy is not configured.\n Please make sure that securitypolicy.zcml is included in site.zcml immediately\n before principals.zcml\n\nHowever, if any non-default security policy is installed, no warning\nis emitted:\n\n >>> from zope.security.management import setSecurityPolicy\n >>> defaultPolicy = setSecurityPolicy(object())\n >>> handler.clear()\n >>> checkSecurityPolicy(event)\n >>> print(handler)\n <BLANKLINE>\n\nClean up:\n\n >>> handler.uninstall()\n\n\nDebug console\n=============\n\nThe debug console lets you have a Python prompt with the full Zope\nenvironment loaded (which includes the ZCML configuration, as well as an open\ndatabase connection).\n\nLet's define a helper to run the debug script and trap SystemExit exceptions\nthat would otherwise hide the output\n\n >>> from __future__ import print_function\n >>> import sys\n >>> from zope.app.appsetup import debug\n >>> def run(*args):\n ... sys.argv[0] = 'debug'\n ... sys.stderr = sys.stdout\n ... try:\n ... debug.main(args)\n ... except SystemExit as e:\n ... print(\"(exited with status %d)\" % e.code)\n\nIf you call the script with no arguments, it displays a brief error message\non stderr\n\n >>> run()\n Error: please specify a configuration file\n For help, use debug -h\n (exited with status 2)\n\nWe need to pass a ZConfig configuration file as an argument\n\n >>> run('-C', 'test.conf.txt')\n The application root is known as `root`.\n\nNow you have the root object from the open database available as a global\nvariable named 'root' in the __main__ module:\n\n >>> main_module = sys.modules['__main__']\n >>> main_module.root # doctest: +ELLIPSIS\n <zope.site.folder.Folder object at ...>\n\nand we have asked Python to enter interactive mode by setting the\nPYTHONINSPECT environment variable\n\n >>> import os\n >>> os.environ.get('PYTHONINSPECT')\n 'true'\n\nWe have to do extra work to honor the PYTHONSTARTUP environment variable:\n\n >>> pythonstartup = os.path.join(os.path.dirname(debug.__file__),\n ... 'testdata', 'pythonstartup.py')\n >>> os.environ['PYTHONSTARTUP'] = pythonstartup\n >>> run('-C', 'test.conf.txt')\n The application root is known as `root`.\n\nYou can see that our pythonstartup file was executed because it changed\nthe prompt\n\n >>> sys.ps1\n 'debug> '\n\n\n\nProduct-specific configuration\n==============================\n\nThe ``product`` module of this package provides a very simple way to deal with\nwhat has traditionally been called \"product configuration\", where \"product\"\nrefers to the classic Zope 2 notion of a product.\n\nThe configuration schema for the application server allows named\n<product-config> sections to be added to the configuration file, and product\ncode can use the API provided by the module to retrieve configuration sections\nfor given names.\n\nThere are two public functions in the module that should be used in normal\noperations, and additional functions and a class that can be used to help with\ntesting:\n\n >>> from __future__ import print_function\n >>> from zope.app.appsetup import product\n\nLet's look at the helper class first, since we'll use it in describing the\npublic (application) interface. We'll follow that with the functions for\nnormal operation, then the remaining test-support functions.\n\n\nFaux configuration object\n-------------------------\n\nThe ``FauxConfiguration`` class constructs objects that behave like the\nZConfig section objects to the extent needed for the product configuration\nAPI. These will be used here, and may also be used to create configurations\nfor testing components that consume such configuration.\n\nThe constructor requires two arguments: the name of the section, and a mapping\nof keys to values that the section should provide. Let's create a simple\nexample:\n\n >>> one = product.FauxConfiguration(\"one\", {})\n >>> one.getSectionName()\n 'one'\n >>> one.mapping\n {}\n\nProviding a non-empty set of key/value pairs trivially behaves as expected:\n\n >>> two = product.FauxConfiguration(\"two\", {\"abc\": \"def\"})\n >>> two.getSectionName()\n 'two'\n >>> two.mapping\n {'abc': 'def'}\n\n\nApplication API\n---------------\n\nThere are two functions in the application interface for this module. One is\nused by the configuration provider, and the other is used by the consumer.\n\nThe provider's API takes a sequence of configuration objects that conform to\nthe behaviors exhibited by the default ZConfig section objects. Since the\n``FauxConfiguration`` class provides these behaviors, we can easily see how\nthis can be used:\n\n >>> product.setProductConfigurations([one, two])\n\nNow that we've established some configuration, we want to be able to use it.\nWe do this using the ``getProductConfiguration()`` function. This function\ntakes a name and returns a matching configuration section if there is one, of\nNone if not:\n\n >>> product.getProductConfiguration(\"one\")\n {}\n\n >>> product.getProductConfiguration(\"not-there\") is None\n True\n\nNote that for a section that exists, only the internal mapping is provided,\nnot the containing section object. This is a historical wart; we'll just need\nto live with it until new APIs are introduced.\n\nSetting the configuration a second time will overwrite the prior\nconfiguration; sections previously available will no longer be:\n\n >>> product.setProductConfigurations([two])\n >>> product.getProductConfiguration(\"one\") is None\n True\n\nThe new sections are available, as expected:\n\n >>> product.getProductConfiguration(\"two\")\n {'abc': 'def'}\n\n\nTest support functions\n----------------------\n\nAdditional functions are provided that make it easier to manage configuration\nstate in testing.\n\nThe first can be used to provide configuration for a single name. The\nfunction takes a name and either a configuration mapping or ``None`` as\narguments. If ``None`` is provided as the second argument, any configuration\nsettings for the name are removed, if present. If the second argument is not\n``None``, it will be used as the return value for ``getProductConfiguration``\nfor the given name.\n\n >>> product.setProductConfiguration(\"first\", None)\n >>> print(product.getProductConfiguration(\"first\"))\n None\n\n >>> product.setProductConfiguration(\"first\", {\"key\": \"value1\"})\n >>> product.getProductConfiguration(\"first\")\n {'key': 'value1'}\n\n >>> product.setProductConfiguration(\"first\", {\"key\": \"value2\"})\n >>> product.getProductConfiguration(\"first\")\n {'key': 'value2'}\n\n >>> product.setProductConfiguration(\"first\", {\"alt\": \"another\"})\n >>> product.getProductConfiguration(\"first\")\n {'alt': 'another'}\n\n >>> product.setProductConfiguration(\"second\", {\"you\": \"there\"})\n >>> product.getProductConfiguration(\"first\")\n {'alt': 'another'}\n >>> product.getProductConfiguration(\"second\")\n {'you': 'there'}\n\n >>> product.setProductConfiguration(\"first\", None)\n >>> print(product.getProductConfiguration(\"first\"))\n None\n\nThe other two functions work in concert, saving and restoring the entirety of\nthe configuration state.\n\nOur current configuration includes data for the \"second\" key, and none for the\n\"first\" key:\n\n >>> print(product.getProductConfiguration(\"first\"))\n None\n >>> print(product.getProductConfiguration(\"second\"))\n {'you': 'there'}\n\nLet's save this state:\n\n >>> state = product.saveConfiguration()\n\nNow let's replace the kitchen sink:\n\n >>> product.setProductConfigurations([\n ... product.FauxConfiguration(\"x\", {\"a\": \"b\"}),\n ... product.FauxConfiguration(\"y\", {\"c\": \"d\"}),\n ... ])\n\n >>> print(product.getProductConfiguration(\"first\"))\n None\n >>> print(product.getProductConfiguration(\"second\"))\n None\n\n >>> product.getProductConfiguration(\"x\")\n {'a': 'b'}\n >>> product.getProductConfiguration(\"y\")\n {'c': 'd'}\n\nThe saved configuration state can be restored:\n\n >>> product.restoreConfiguration(state)\n\n >>> print(product.getProductConfiguration(\"x\"))\n None\n >>> print(product.getProductConfiguration(\"y\"))\n None\n\n >>> print(product.getProductConfiguration(\"first\"))\n None\n >>> print(product.getProductConfiguration(\"second\"))\n {'you': 'there'}\n\nThere's an additional function that can be used to load product configuration\nfrom a file object; only product configuration components are accepted. The\nfunction returns a mapping of names to configuration objects suitable for\npassing to ``setProductConfiguration``. Using this with\n``setProductConfigurations`` would require constructing ``FauxConfiguration``\nobjects.\n\nLet's create some sample configuration text:\n\n >>> product_config = '''\n ... <product-config product1>\n ... key1 product1-value1\n ... key2 product1-value2\n ... </product-config>\n ...\n ... <product-config product2>\n ... key1 product2-value1\n ... key3 product2-value2\n ... </product-config>\n ... '''\n\nWe can now load the configuration using the ``loadConfiguration`` function:\n\n >>> import io\n >>> import pprint\n\n >>> sio = io.StringIO(product_config)\n >>> config = product.loadConfiguration(sio)\n\n >>> pprint.pprint(config, width=1)\n {'product1': {'key1': 'product1-value1',\n 'key2': 'product1-value2'},\n 'product2': {'key1': 'product2-value1',\n 'key3': 'product2-value2'}}\n\nExtensions that provide product configurations can be used as well:\n\n >>> product_config = '''\n ... %import zope.app.appsetup.testproduct\n ...\n ... <testproduct foobar>\n ... </testproduct>\n ...\n ... <testproduct barfoo>\n ... key1 value1\n ... key2 value2\n ... </testproduct>\n ... '''\n\n >>> sio = io.StringIO(product_config)\n >>> config = product.loadConfiguration(sio)\n\n >>> pprint.pprint(config, width=1)\n {'barfoo': {'key1': 'value1',\n 'key2': 'value2',\n 'product-name': 'barfoo'},\n 'foobar': {'product-name': 'foobar'}}\n\n\nChangelog\n=========\n\n5.0 (2023-02-09)\n----------------\n\n- Add support for Python 3.9, 3.10, 3.11.\n\n- Drop support for Python 2.7, 3.5, 3.6.\n\n\n4.2.0 (2020-05-20)\n------------------\n\n- Drop support for ``python setup.py test``.\n\n- Add support for Python 3.8.\n\n- Drop support for Python 3.4.\n\n\n4.1.0 (2018-12-15)\n------------------\n\n- Add support for Python 3.6, 3.7 and PyPy3.\n\n- Drop support for Python 3.3.\n\n\n4.0.0 (2016-08-08)\n------------------\n\n- Add dependency on ``zdaemon`` (split off from ``ZODB``).\n\n- Claim support for Python 3.4, 3.5 and PyPy which requires\n ``zope.app.publication`` >= 4.0.\n\n- Drop Python 2.6 support.\n\n4.0.0a1 (2013-03-03)\n--------------------\n\n- Added support for Python 3.3.\n\n- Replaced deprecated ``zope.interface.implements`` usage with equivalent\n ``zope.interface.implementer`` decorator.\n\n- Dropped support for Python 2.4 and 2.5.\n\n\n3.16.0 (2011-01-27)\n-------------------\n\n- Added stacking of storages for layer/test level setup separation in derived\n ZODBLayers.\n\n\n3.15.0 (2010-09-25)\n-------------------\n\n- Updated tests to run with `zope.testing >= 3.10`, requiring at least this\n version and `zope.testrunner`.\n\n- Switch ``IErrorReportingUtility copy_to_zlog`` field to ``True``.\n\n- Using Python's `doctest` module instead of depreacted\n `zope.testing.doctest`.\n\n\n3.14.0 (2010-04-13)\n-------------------\n\n- Made `zope.testing` an optional (test) dependency.\n\n- Removed test dependency on `zope.app.testing`.\n\n\n3.13.0 (2009-12-24)\n-------------------\n\n- Import hooks functionality from zope.component after it was moved there from\n zope.site.\n\n- Import ISite from zope.component after it was moved there from\n zope.location. This lifts the dependency on zope.location.\n\n- Added missing install dependency on `zope.testing`.\n\n\n3.12.0 (2009-06-20)\n-------------------\n\n- Using ``zope.processlifetime`` interfaces and implementations\n directly instead of BBB imports from ``zope.app.appsetup``.\n\n- Got rid of depencency on ``zope.app.component``.\n\n- Got rid of test dependency on ``zope.app.security``.\n\n\n3.11 (2009-05-13)\n-----------------\n\n- Event interfaces / implementations moved to ``zope.processlifetime``,\n version 1.0. Depend on this package, and add BBB imports.\n\n\n3.10.1 (2009-03-31)\n-------------------\n\n- Fixed a ``DeprecationWarning`` introduced in 3.10.0.\n\n- Added doctests to long description to show up at pypi.\n\n\n3.10.0 (2009-03-19)\n-------------------\n\n- Finally deprecate the \"asObject\" argument of helper functions in the\n ``zope.app.appsetup.bootstrap`` module. If your code uses any of these\n functions, please remove the \"asObject=True\" argument passing anywhere,\n because the support for that argument will be dropped soon.\n\n- Move session utility bootstrapping logic from ``zope.session`` into this\n package. This removes a dependency from zope.session to this package.\n\n- Remove one more deprecated function.\n\n\n3.9.0 (2009-01-31)\n------------------\n\n- Use ``zope.site`` instead of ``zope.app.folder`` and\n ``zope.app.component``.\n\n- Use ``zope.container`` instead of ``zope.app.container``.\n\n- Move error log bootstrapping logic from ``zope.error`` into this\n package. This removes a dependency from zope.error to this\n package. Also added a test for bootstrapping the error log here,\n which was missing in ``zope.error``.\n\n\n3.8.0 (2008-08-25)\n------------------\n\n- Feature: Developed an entry point that allows you to quickly bring up an\n application instance for debugging purposes. (Implemented by Marius Gedminas\n and Stephan Richter.)\n\n\n3.7.0 (2008-08-19)\n------------------\n\n- Added ``.product.loadConfiguration`` test-support function; loads product\n configuration (only) from a file object, allowing test code (including\n setup) to make use of the same configuration schema support used by normal\n startup.\n\n\n3.6.0 (2008-07-23)\n------------------\n\n- Added additional test support functions to set the configuration for a\n single section, and save/restore the entire configuration.\n\n\n3.5.0 (2008-06-17)\n------------------\n\n- Added helper class for supporting product configuration tests.\n\n- Added documentation for the product configuration API, with tests.\n\n\n3.4.1 (2007-09-27)\n------------------\n\n- Egg was faulty, re-released.\n\n\n3.4.0 (2007-09-25)\n------------------\n\n- Initial documented release.\n\n- Reflect changes form zope.app.error refactoring.\n",
"bugtrack_url": null,
"license": "ZPL 2.1",
"summary": "Zope app setup helper",
"version": "5.0",
"split_keywords": [
"zope3",
"app",
"setup"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "d3b35bca403f1ec174b28e7e6991c7b481b44e4fd2c0cd01bc0243d590b271a2",
"md5": "74a8acd96b7cffdc1fa04a573fd5e9b3",
"sha256": "9725db99c684f80724fbe414754ec5da7c217956abd1d96c378869473a1d41e3"
},
"downloads": -1,
"filename": "zope.app.appsetup-5.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "74a8acd96b7cffdc1fa04a573fd5e9b3",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.7",
"size": 35605,
"upload_time": "2023-02-09T10:52:41",
"upload_time_iso_8601": "2023-02-09T10:52:41.083154Z",
"url": "https://files.pythonhosted.org/packages/d3/b3/5bca403f1ec174b28e7e6991c7b481b44e4fd2c0cd01bc0243d590b271a2/zope.app.appsetup-5.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "83b820dd498f46973f3ca448971574700619f35fbfc18d82d20be807392752d4",
"md5": "b9672d1e82dec8e4b55ce22b4e5d0937",
"sha256": "0e0bd9f719fa2c5e893b661a5438e04dcea2b693650bcf5c27ebec7e2b7b50c8"
},
"downloads": -1,
"filename": "zope.app.appsetup-5.0.tar.gz",
"has_sig": false,
"md5_digest": "b9672d1e82dec8e4b55ce22b4e5d0937",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.7",
"size": 32157,
"upload_time": "2023-02-09T10:52:43",
"upload_time_iso_8601": "2023-02-09T10:52:43.453152Z",
"url": "https://files.pythonhosted.org/packages/83/b8/20dd498f46973f3ca448971574700619f35fbfc18d82d20be807392752d4/zope.app.appsetup-5.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-02-09 10:52:43",
"github": true,
"gitlab": false,
"bitbucket": false,
"github_user": "zopefoundation",
"github_project": "zope.app.appsetup",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"tox": true,
"lcname": "zope.app.appsetup"
}
JSON
