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.