Configuration and setup

Introduction

APIs for configuring cryptoassets.core.

Config coding conventions

  • All config variables use underscore notitation (e.g. status_server instead of status-server) to be consistent with Python code

Cryptoassets Application

Cryptoassets application manager.

class cryptoassets.core.app.Subsystem[source]

Enumerator for available cryptoassets library subsystems.

Depending on your application entry point and user case, you might not want to initialize all features of cryptoassets framework within your Python application. For example, multiple web server processes cannot initialize status server each, but this functinonality is purposed for the daemon applications.

database = None

Initialize database connections

status_server = None

Open HTTP status server running

backend = None

Try to connect to backend APIs

broadcast = None

Start processes and threads for broadcasting outgoing transactions

incoming_transactions = None

Start processes and threads for walletnotify hooks

event_handler_registry = None

Post notifications

class cryptoassets.core.app.CryptoAssetsApp(subsystems=[<Subsystem.database: 1>, <Subsystem.backend: 3>])[source]

This class ties all strings together to make a runnable cryptoassets app.

Initialize a cryptoassets framework.

Parameters:subsystems – Give the list of subsystems you want to initialize. Because the same configuration file can be used by e.g. both web server and command line application, and config file parts like status server are only relevant in the context of the command line application, this can tell the cryptoassets framework how to set up itself. By default it initializes all the subsystems.
engine = None

SQLAlchemy database used engine

coins = None

cryptoassets.core.coin.registry.CoinRegistry instance

event_handler_registry = None

Dict of notify handlers

status_server = None

Configured status server See notes in cryptoassets.core.service.main.Service

transaction_retries = None

The number of attempts we try to replay conflicted transactions. Set by configuration.

conflict_resolver = None

cryptoassets.core.utils.conflictresolver.ConflictResolver instance we use to resolve database conflicts

is_enabled(subsystem)[source]

Are we running with a specific subsystem enabled.

setup_session(transaction_retries=3)[source]

Configure SQLAlchemy models and transaction conflict resolutoin.

Also, bind created cryptocurrency models to their configured backends.

open_session()[source]

Get new read-write session for the database.

open_readonly_session()[source]

Get new read-only access to database.

This session can never write to db, so db can ignore transactions and optimize for speed.

TODO

create_tables()[source]

Create database tables.

Usually call only once when settings up the production database, or every time unit test case runs.

clear_tables()[source]

Delete all data in the database, but leaving tables intact.

Useful to get clean state in unit testing.

Warning

No questions asked. Don’t dare to call outside testing or your data is really gone.

Configuration API

Configuring cryptoassets.core for your project.

Setup SQLAlchemy, backends, etc. based on individual dictionaries or YAML syntax configuration file.

cryptoassets.core.configure.logger = None

XXX: logger cannot be used in this module due to order of logger initialization?

exception cryptoassets.core.configure.ConfigurationError[source]

ConfigurationError is thrown when the Configurator thinks somethink cannot make sense with the config data.

class cryptoassets.core.configure.Configurator(app, service=None)[source]

Read configuration data and set up Cryptoassets library.

Reads Python or YAML format config data and then setss cryptoassets.core.app.CryptoassetsApp up and running accordingly.

Parameters:
config = None

Store full parsed configuration as Python dict for later consumption

setup_engine(configuration)[source]

Setup database engine.

See sqlalchemy.engine_from_config for details.

TODO: Move engine to its own module?

Parameters:configuration (dict) – engine configuration section
setup_backend(coin, data)[source]

Setup backends.

Parameters:data – dictionary of backend configuration entries
setup_model(module)[source]

Setup SQLAlchemy models.

Parameters:module – Python module defining SQLAlchemy models for a cryptocurrency
Returns:cryptoassets.core.coin.registry.CoinModelDescription instance
setup_event_handlers(event_handler_registry)[source]

Read notification settings.

Example notifier format:

{
    "shell": {
        "class": "cryptoassets.core.event_handler_registry.shell.ShellNotifier",
        "script": "/usr/bin/local/new-payment.sh"
    }
}
setup_status_server(config)[source]

Prepare status server instance for the cryptoassets helper service.

setup_service(config)[source]

Configure cryptoassets service helper process.

load_from_dict(config)[source]

Load configuration from Python dictionary.

Populates app with instances required to run cryptocurrency.core framework.

classmethod setup_service_logging(config)[source]

Setup Python loggers for the helper service process.

Parameters:config – service -> logging configure section.
classmethod setup_startup(config)[source]

Service helper process specific setup when launched from command line.

Reads configuration service section, ATM only interested in logging subsection.

This is run before the actual Cryptoassets application initialization. We need logging initialized beforehand so that we can print out nice $VERSIONNUMBER is starting message.

static prepare_yaml_file(fname)[source]

Extract config dictionary from a YAML file.

load_yaml_file(fname, overrides={})[source]

Load config from a YAML file.

Parameters:
  • fname – Path to the YAML file
  • overrides – Python nested dicts for specific setting overrides