You're reading an old version of this documentation. For up-to-date information, please have a look at v0.6.

pymetacode.configuration module

Configuration handling of the pymetacode package.

Key to the rather simplistic and user-friendly command-line interface (CLI) of the pymetacode package is a configuration stored within the package root directory and read by all the code generators residing in the pymetacode.coding module.

The Configuration class provides the necessary functionality for creating a default configuration file as well as for reading the configuration from a file for use with the code generators.

class pymetacode.configuration.Configuration

Bases: pymetacode.utils.ToDictMixin

Configuration used for generating code.

A necessary prerequisite for all the code generators is a minimal set of configuration values that are persistently stored in a file within the project root directory and read from there accordingly.

The class provides the unique place to structure this configuration.


Configuration on the package level

The following fields are currently available:


Name of the package, following PEP 8 conventions


Name of the author(s) of the package

In case of more than one author, use a comma-separated list


Email address(es) of the author(s) of the package

In case of more than one author, use a comma-separated list


Year the package has been created

Can be a span of years, but will typically be a single date when a package is created. (Change afterwards if needed.)


Short description of the package, typically in one short sentence.

Gets used as first line in the README and documentation index, and is used as package description on PyPI. This is separate from the long description (in the file, this is usually the contents of the README file).


A series of different URLs, as set in the file.

These URLs are used on PyPI, hence choose with care. Typically, you would set main (the homepage of the package), documentation, and source (GitHub or else).


List of keywords (strings) describing the package.

These keywords are used, i.a., on PyPI to find your package. Hence, choose with care.


List of packages required by your package.

This should be kept at an absolute minimum. Note that many packages often used as dependencies, such as numpy or matplotlib, come with many further dependencies.

Within the file, additional requirements for documentation (docs) and development (dev) are set, but these are only special requirements for developers.

If you want to create a GUI (see below), the requirements are automatically added for you as well.


Abbreviation of the license of your package.

Currently, only two licenses are supported: “BSD” and “GPLv3”. The default license, if none is given, is “BSD”.

Note that choosing a license here will copy the corresponding license text to the file LICENSE in your project root directory.

New in version 0.5.




Configuration regarding the documentation of the package

The following fields are currently available:


Filename of a logo file.

If no logo is provided, no logo will be added to your documentation.


Filename of the favicon file.

A favicon is used as icon in your webbrowser and should be provided as Windows Icon file.


Lower-case abbreviation of the language of your documentation.

Two-letter abbreviations are used, and default is “en”. Note that current versions of Sphinx require a language to be set in the configuration file.




Configuration regarding the metacode

New in version 0.3.

The following fields are currently available:


Whether to add logging to your package.

Default: False


Whether to instantiate a git repository for your package.

It is highly recommended to use git/version control for developing any package. If you set this option to true, not only will a git repository be initialised for your package, but appropriate pre-commit hooks installed that take care of automatically incrementing the version number and auto-formatting your code on every commit.

Default: False


Whether to add a GUI to your package.

Sometimes, GUIs are a necessary part of a package. If you know already when creating the package that you will need a GUI, set this option to true. This will not only create the entire directory structure for your GUI, but set a few things in and elsewhere accordingly.

Default: False




Configuration regarding the GUI

New in version 0.4.

The following fields are currently available:


Whether to add a splash screen to your GUI main window.

Default: True


Name of the organisation the GUI belongs to.

This setting is used by Qt to store application settings. Hence, it is crucial to set this to a sensible value.


Domain name of the organisation the GUI belongs to.

This setting is used by Qt in some operating systems to store application settings. Hence, it is crucial to set this to a sensible value.




ValueError – Raised if no dict is provided.


The following examples demonstrate how to use the CLI from the terminal, rather than how to use this class programmatically.

The first step when creating a new package is to write a config file that can be filled with sensible content afterwards:

pymeta write config to mypackage_config.yaml

This would write the default configuration to “mypackage_config.yaml”. Change all values in this file according to your needs.

Changed in version 0.3: New property “options”, moved key “git” to property “options”

Changed in version 0.4: New property “gui”

Changed in version 0.5: New key “license” in property “package”


Create dictionary containing public attributes of an object.


public_attributes – Ordered dictionary containing the public attributes of the object

The order of attribute definition is preserved

Return type



Set attributes from dictionary.


dict (dict) – Dictionary containing information of a task.


ValueError – Raised if no dict is provided.


Write to YAML file.


name (str) – Name of the YAML file to write to.


Read from YAML file.


name (str) – Name of the YAML file to read from.