Implement a more robust config store
JSON config files are great for small-scale projects, but a more robust solution is needed for larger scale.
https://github.com/dglazkov/polymath-host uses Firestore, for example. Here's a path to get there, expressed as a set of interlocked patterns:
- Configuration is accessed via
*Configclasses. Each class takes in a simpledict[str, str]and offers simple accessors with good defaults and type conversion if necessary. For example,HostConfig,InfoConfig, etc. - The dictionary is produced by the
*ConfigStoreclass. The class is not specialized to each kind of config, it's just a way to read the store. It is specialized for the type of storage:JSONConfigStore,FirestoreConfigStore, etc. - Each
*Configclass has acreateclass method that takes a*ConfigStoreclass to produce the right instance.
(to be continued)
- The
*ConfigStoreclass operates on some store, so it must be given some knowledge about location of the store (file path in JSON, document/collection path in Firestore). This is knowledge is passed as constructor arguments. - Instances of
*ConfigStoreare produced by*ConfigLoader. This class knows all locations of files and paths to instantiate the right*ConfigStore, and has methods for each. There is oneConfigStoreper type of storage. - When writing a Polymath app, developer instantiates a
*ConfigLoaderof the kind that's appropriate for their setup. Everything else within the Polymath library is oblivious to specifics. - Developer can also create their own
*ConfigLoaderinstance. For example, they can introduce a different kind of store, or they can use it to mash existing ones together: one kind of store for directory and another for host, etc.
@jkomoros @dalmaer PTAL
I'll start hacking on this and see what happens.
d7e5e8519847697692d6c481b586f7310b6a8f2b was part of this.
f4396ee9b942a8df6679dcf202b55e31094e98f7 and fd04a01a901c9dd5483f8e6cb3832c6a41037f1e too! I am not great at my commit messages.
So I have three different kinds of stores: JSONConfigStore, FirestoreConfigStore, and EnvConfigStore. All three are working ™️ andserver.py currently uses JSONConfigStore. I checked, and it's a two-line change to swap it over to Firestore.
Oh yeah! and server.py also uses EnvConfigStore for the keys etc. This means that we can easily shift this to JSON or Firestore if want.
Would it be silly meta to have a config that sets up the type of store so it's zero loc?
Eg. Either an ENV that has the type and then info (JSON and file say). Or JSON (points to Firestore).
Not silly at all!
- [x] Collapse
*ConfigLoaderinfo*ConfigStore - [x] Rename
loadtoget - [x] Implement
*ConfigStore.set
- [x] Use docstrings to document fields in
*Config
- [ ] Omit defaults as well as empties in
*Config.to_dict - [ ] Add
defaultproperty toAttrDoc - [ ] Add
requiredproperty toAttrDoc