Glossary¶

ad hoc script¶

Python script (text) file used for ad-hoc automation etc. See also Ad Hoc Scripts.

app¶

Depending on context, may refer to the software application overall, or the app name, or the app handler.

app database¶

The main database used by the app. There is normally just one database (for simple apps) which uses PostgreSQL for the backend. The app database contains the settings table.

app dir¶

Folder containing app-specific config files, log files, etc. Usually this is named app and is located at the root of the virtual environment.

Can be retrieved via get_appdir().

app enum¶

Python module whose namespace contains all the “enum” values used by the app. Available on the app handler as enum.

app handler¶

Python object representing the core handler for the app. There is normally just one “global” app handler; see also App Handler.

app model¶

Python module whose namespace contains all the data models used by the app.

app name¶

Code-friendly name for the underlying app/config system (e.g. wutta_poser).

This must usually be specified as part of the call to make_config() and is then available on the config object appname and the app handler appname.

See also AuthHandler.

command¶

A top-level command line interface for the app. Note that top-level commands don’t usually “do” anything per se, and are mostly a way to group subcommands. See also Command Line Interface.

config¶

Depending on context, may refer to any of: config file, config object, config setting. See also Configuration.

config extension¶

A registered extension for the config object. What happens is, a config object is created and then extended by each of the registered config extensions.

The intention is that all config extensions will have been applied before the app handler is created.

config file¶

A file which contains config settings. See also Config Files.

config object¶

Python object representing the full set of config settings for the app. Usually it gets some of the settings from config files, but it may also get some from the settings table. See also Config Object.

config setting¶

The value of a setting as obtained from a config object. Depending on context, sometimes this refers specifically to values obtained from the settings table as opposed to config file. See also Config Settings.

data model¶

Usually, a Python class which maps to a database table.

database¶

Generally refers to a relational database which may be queried using SQL. More specifically, one supported by SQLAlchemy.

Most apps will have at least one app database.

db session¶

The “session” is a SQLAlchemy abstraction for an open database connection, essentially.

In practice this generally refers to a Session instance.

email handler¶

The handler responsible for sending email on behalf of the app.

Default is EmailHandler.

entry point¶

This refers to a “setuptools-style” entry point specifically, which is a mechanism used to register “plugins” and the like. This lets the app / config discover features dynamically. Most notably used to register commands and subcommands.

For more info see the Python Packaging User Guide.

handler¶

Similar to a “plugin” concept but only one handler may be used for a given purpose. See also Handlers.

package¶

Generally refers to a proper Python package, i.e. a collection of modules etc. which is installed via pip. See also Package Installation.

provider¶

Python object which “provides” extra functionality to some portion of the app. Similar to a “plugin” concept; see Providers.

settings table¶

Table in the app database which is used to store config settings. See also Settings Table.

subcommand¶

A top-level command may expose one or more subcommands, for the overall command line interface. Subcommands are usually the real workhorse; each can perform a different function. See also Command Line Interface.

virtual environment¶

This term comes from the broader Python world and refers to an isolated way to install packages. See also Virtual Environment.