Main approach and ideas

[thorwhalen]

The idea here is to be able to deal with configuration problems simply and as separated as possible from other concerns (such as formats, file location and type, etc.). We do so by using, when ever we can, builtin interfaces such as mappings and sequences.

Consider past situations where you'd want to edit your ci.yml or .gitignore, consider how you'd automate this edition, and consider how you'd do it if you were dealing with a simple list (of lines of .gitignore) or dict
(note that the values could be nested; could be dicts or lists themselves).

Working with lists or dicts is closer to the domain of "creating and maintaining" configurations, and allow more separation from the file implementation detail.

Relevant packages

Editing

• dol is the great core of many mapping abstractions
• config2py builds on dol, but specializes to configuration needs. This is probably where you want to put, or aggregate most of your work.
• creek was originally meant to be the dol (data-object-layer) for streams, i.e. iterator and iterables, but would be a sensible place to put sequence object layers.

Creation

Take note of the (placeholder) project for general templated creation (think of f-strings, generalized to any python objects (so dicts, lists, etc.)): embody.

Also relevant:

• SlabsIter defines a sequence of instructions to both read from source streams and create others based on these. It's now in the know project, but will probably be moved to creek or meshed.
• meshed is about connecting/linking python objects into aggregate objects. Most known objects are Pipe (function composition) and DAG. meshed is a well weathered project at this point.
• slink, which is focused on generating sequential data for testing. A lot of it's ideas/code should probably be refactored to use things from meshed and embody.

For the specific case of creating templated projects there's cookiecutter.
Never used, but could use going forward.
Our package for that is wads.

[thorwhalen]

The config

The word config is mentioned in the 58 issues.
The themes that come up are

• GUI configs editor (e.g. Configs CRUD UI)
• Where should configs be stored/sourced (e.g. Where should we put app/package data, and how do we manage that aspect?)
• How should we interface with them (e.g. Config object versus flat explicit arguments)
• and more...

The proposed design has been (for awhile) quite straightforward: Interface with configs through a mapping.
Fleshed out a bit, this means:

Encapsulate

• where configs come from (yaml, json, environment variable, etc.)
• whether there's one or several sources/targets for configs (e.g. using mapping unions or collection.ChainMap)
• whether to trigger a user input request for a config not found
  through a mapping interface

Depend on the mapping interface to build UIs (GUI, CLI, http services, python objects) to view and edit configs.

I'm accumulating the encapsulation tools in config2py.

We can discuss if it makes sense to also put the UI dispatching tools there, or rather have that stuff as an (important) section of UI dispatching packages (e.g. front).

(Opened a private discussion about this here)