- use a config library (or write your own) it should read the settings.config from the root home folder.
- This library should also read settings.local.config (or equivalent.) make a git IGNORE rule for the settings.local.config so you would put credentials here and they won't be checked in to the repo.
- This local config should be read and merged into the base config by your config library (deep merge).
- Further, I like to pull additional config from the DB (for user level settings.) the fs is necessary for bootstrapping into the DB, which then may load additional preferences.
- This config format should be whatever you're comfortable with, JSON , YAML, TOML, .py/js, etc. your stack will have its own selection (and behavior) for config libraries.
And now, make sure that config is loaded and made available at the earliest point in code, and everyone can use it EASILY.
You could have this stashed into a user or system cache which your tools can then spy on to see what settings are available whichever place in code.
Settings, access control, preferences, etc. can all fit this format.
By using the git excluded '.local.' layer you can ensure API keys are never checked into git.
* root home folder; that's the application home, one level ABOVE whatever passes for web root. This file should not be accessible to anyone outside of the application.
We’ve done this using Django’s admin portal to let non-technical stakeholders work with database records, and it works well enough. It creates a self-serve scenario for some users, for some kinds of tasks.
The challenge is (as always) finding the right level of abstraction. A premature, wrong abstraction is way worse than making it work by hard coding some logic in the code, or (gasp) just copying and pasting the code a few times, until it’s clear which direction the abstraction is pointing, and at which level it’s operating at.
Like if you start building some generic workflow engine that doesn’t match your actual needs, you’re going to build something that’s clunky to work with, and that it’s hard to backtrack from the design decisions made. It’s better to hard code or duplicate something and remain noncommittal about architecture and design choices until you have clarity.
In practice it’s always a dance. You have to push the boundary to some degree or you’ll never build anything tangible. The usual advice of “just ship something” is not bad here, as shipping a complete failure will be a more information-rich data stream about the right direction than more planning.
- use a config library (or write your own) it should read the settings.config from the root home folder.
- This library should also read settings.local.config (or equivalent.) make a git IGNORE rule for the settings.local.config so you would put credentials here and they won't be checked in to the repo.
- This local config should be read and merged into the base config by your config library (deep merge).
- Further, I like to pull additional config from the DB (for user level settings.) the fs is necessary for bootstrapping into the DB, which then may load additional preferences.
- This config format should be whatever you're comfortable with, JSON , YAML, TOML, .py/js, etc. your stack will have its own selection (and behavior) for config libraries.
And now, make sure that config is loaded and made available at the earliest point in code, and everyone can use it EASILY.
You could have this stashed into a user or system cache which your tools can then spy on to see what settings are available whichever place in code.
Settings, access control, preferences, etc. can all fit this format.
By using the git excluded '.local.' layer you can ensure API keys are never checked into git.