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 as well as data models.

For more info see App Database.

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

This refers to the canonical name for the underlying app/config system. It does not refer to the overall app; contrast with app title.

In most cases (i.e. by default) this will simply be wutta. This value affects the naming conventions for config files as well as setting names etc.

The primary reason for this abstraction is so that the Rattail Project could leverage the Wutta config logic without having to rewrite all config files in the wild.

See also appname.

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 app name which serves a very different purpose.

auth handler

A handler responsible for user authentication and authorization (login, permissions) and related things.

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.

The app (assuming it has an app database) will have an “official” set of data models, represented as the app model.

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. See also Databases.

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.

install handler

The handler responsible for installing a new instance of the app.

Default is InstallHandler.

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 with a custom arg set. 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.