OOPS report model and default allocation/[de]serialization.
Project description
**************************
python-oops: Error reports
**************************
Copyright (c) 2011, Canonical Ltd
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation, version 3 only.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
GNU Lesser General Public License version 3 (see the file LICENSE).
The oops project provides an in-memory model and basic serialisation,
deserialisation and allocation of OOPS reports. An OOPS report is a report
about something going wrong in a piece of software... thus, an 'oops' :)
This core package is rarely used directly: most programs or services that want
to generate OOPS reports will do so via a framework specific adapter (e.g.
python-oops_wsgi).
Dependencies
============
* Python 2.6+ or 3.3+
* pytz (http://pypi.python.org/pypi/pytz/)
Testing Dependencies
====================
* subunit (http://pypi.python.org/pypi/python-subunit) (optional)
* testtools (http://pypi.python.org/pypi/testtools)
Usage
=====
In Python, OOPS reports are dicts with some well known keys, but extensible
simply by adding as many additional keys asneeded. The only constraint is that
the resulting dict must be bson serializable : this is the standard to which
new serializers are held. Some existing serializers cannot handle this degree
of extensability and will ignore additional keys, and/or raise an error on keys
they expect but which contain unexpected data.
Typical usage:
* When initializing your script/app/server, create a Config object::
>>> from oops import Config
>>> config = Config()
* New reports will be based on the template report::
>>> config.template
{}
* You can edit the template report (which like all reports is just a dict)::
>>> config.template['branch_nick'] = 'mybranch'
>>> config.template['appname'] = 'demo'
* You can supply a callback (for instance, to capture your process memory usage
when the oops is created, or to override / tweak the information gathered by an
earlier callback)::
>>> mycallback = lambda report, context: None
>>> config.on_create.append(mycallback)
The context parameter is also just dict, and is passed to all the on_create
callbacks similarly to the report. This is used to support passing information
to the on_create hooks. For instance, the exc_info key is used to pass in
information about the exception being logged (if one was caught).
* Later on, when something has gone wrong and you want to create an OOPS
report::
>>> report = config.create(context=dict(exc_info=sys.exc_info()))
>>> report
{'appname': 'demo', 'branch_nick': 'mybranch'}
* And then send it off for storage::
>>> config.publish(report)
[]
* Note that publish returns a list - each item in the list is the id allocated
by the particular repository that recieved the report. (Id allocation is up
to the repository). Publishers should try to use report['id'] for the id, if it
is set. This is automatically set to the id returned by the previous publisher.
If publish returns None, then the report was filtered and not passed to any
publisher (see the api docs for more information).
>>> 'id' in report
False
>>> def demo_publish(report):
... return ['id 1']
>>> config.publisher = demo_publish
>>> config.publish(report)
['id 1']
>>> report['id']
'id 1'
* The pprint_to_stream publisher will print out reports to a stream after
pprinting them. This can be very helpful for interactive use.
* The related project oops_datedir_repo contains a local disk based repository which
can be used as a publisher.
More coming soon.
Installation
============
Either run setup.py in an environment with all the dependencies available, or
add the working directory to your PYTHONPATH.
Development
===========
Upstream development takes place at https://launchpad.net/python-oops.
To setup a working area for development, if the dependencies are not
immediately available, you can use ./bootstrap.py to create bin/buildout, then
bin/py to get a python interpreter with the dependencies available.
To run the tests use the runner of your choice, the test suite is
oops.tests.test_suite.
For instance::
$ bin/py -m testtools.run oops.tests.test_suite
Alternative you can use the testr command from testrepository::
$ testr run
python-oops: Error reports
**************************
Copyright (c) 2011, Canonical Ltd
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation, version 3 only.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
GNU Lesser General Public License version 3 (see the file LICENSE).
The oops project provides an in-memory model and basic serialisation,
deserialisation and allocation of OOPS reports. An OOPS report is a report
about something going wrong in a piece of software... thus, an 'oops' :)
This core package is rarely used directly: most programs or services that want
to generate OOPS reports will do so via a framework specific adapter (e.g.
python-oops_wsgi).
Dependencies
============
* Python 2.6+ or 3.3+
* pytz (http://pypi.python.org/pypi/pytz/)
Testing Dependencies
====================
* subunit (http://pypi.python.org/pypi/python-subunit) (optional)
* testtools (http://pypi.python.org/pypi/testtools)
Usage
=====
In Python, OOPS reports are dicts with some well known keys, but extensible
simply by adding as many additional keys asneeded. The only constraint is that
the resulting dict must be bson serializable : this is the standard to which
new serializers are held. Some existing serializers cannot handle this degree
of extensability and will ignore additional keys, and/or raise an error on keys
they expect but which contain unexpected data.
Typical usage:
* When initializing your script/app/server, create a Config object::
>>> from oops import Config
>>> config = Config()
* New reports will be based on the template report::
>>> config.template
{}
* You can edit the template report (which like all reports is just a dict)::
>>> config.template['branch_nick'] = 'mybranch'
>>> config.template['appname'] = 'demo'
* You can supply a callback (for instance, to capture your process memory usage
when the oops is created, or to override / tweak the information gathered by an
earlier callback)::
>>> mycallback = lambda report, context: None
>>> config.on_create.append(mycallback)
The context parameter is also just dict, and is passed to all the on_create
callbacks similarly to the report. This is used to support passing information
to the on_create hooks. For instance, the exc_info key is used to pass in
information about the exception being logged (if one was caught).
* Later on, when something has gone wrong and you want to create an OOPS
report::
>>> report = config.create(context=dict(exc_info=sys.exc_info()))
>>> report
{'appname': 'demo', 'branch_nick': 'mybranch'}
* And then send it off for storage::
>>> config.publish(report)
[]
* Note that publish returns a list - each item in the list is the id allocated
by the particular repository that recieved the report. (Id allocation is up
to the repository). Publishers should try to use report['id'] for the id, if it
is set. This is automatically set to the id returned by the previous publisher.
If publish returns None, then the report was filtered and not passed to any
publisher (see the api docs for more information).
>>> 'id' in report
False
>>> def demo_publish(report):
... return ['id 1']
>>> config.publisher = demo_publish
>>> config.publish(report)
['id 1']
>>> report['id']
'id 1'
* The pprint_to_stream publisher will print out reports to a stream after
pprinting them. This can be very helpful for interactive use.
* The related project oops_datedir_repo contains a local disk based repository which
can be used as a publisher.
More coming soon.
Installation
============
Either run setup.py in an environment with all the dependencies available, or
add the working directory to your PYTHONPATH.
Development
===========
Upstream development takes place at https://launchpad.net/python-oops.
To setup a working area for development, if the dependencies are not
immediately available, you can use ./bootstrap.py to create bin/buildout, then
bin/py to get a python interpreter with the dependencies available.
To run the tests use the runner of your choice, the test suite is
oops.tests.test_suite.
For instance::
$ bin/py -m testtools.run oops.tests.test_suite
Alternative you can use the testr command from testrepository::
$ testr run
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
oops-0.0.14.tar.gz
(8.9 kB
view details)
File details
Details for the file oops-0.0.14.tar.gz
.
File metadata
- Download URL: oops-0.0.14.tar.gz
- Upload date:
- Size: 8.9 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | f9756304978201786f0c8817062acbce64ea0c1f4bb23ddcbb2cf1d9b24eaeb2 |
|
MD5 | fa649af6195e0ab6cb1ebbec80f0a882 |
|
BLAKE2b-256 | 8e51710eef3b4d21f5f2910953331d6e6cf0c60b72433f27445f115d1a616ca9 |