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.

app handler

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

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 the human-friendly app title.

app provider

A provider which pertains to the app handler. See App Providers.

app title

Human-friendly name for the app (e.g. “Wutta Poser”).

See also the code-friendly app name.

command

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

config

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

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.

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.

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 the real workhorse; each can perform a different function. See also Subcommands.

virtual environment

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