Should be used?

[haizaar]

Good date,

I'm searching for config management library that supports yaml files and overrides. This library seem to fit the bill perfectly. I also like schema/default approach a lot. Env vars is a nice bonus; and it even integrates with click which we use heavily as well.

However I stumbled upon a strange comment you left here. Do you suggest this library should not be used? - With over 300 commits and 63 releases it looks pretty serous, and I've yet found any good alternatives.

[jbasko]

Yes, I do NOT recommend using this anymore. I think it tries to do too many things at the same time and therefore is not great in either. I personally stopped using it in my projects and at the moment I have no immediate plans to return to it unless I have a project which has a lot of configuration passed through files.

It could only be useful for someone who doesn't intend to build any tooling around it and would be happy to pin an exact version number. There are just too many entry points and then any changes to the library will most likely break your code.

If you are using just environment variables, I am using my own wr-profiles https://github.com/jbasko/wr-profiles (v4.1.1) in production in several places. It's Python 3.6+ only.

The fact that there are many commits and releases only suggests one has toiled a lot and nothing else :)

Thanks for asking before using.

[haizaar]

Thanks for answering (and writing the lib :).

A more general question then, please.

Suppose you have a microservice. It has some core parameters, e.g. max_connections that change rarely, but you still want to be able to change them without altering code / rebuilding docker image. Then it has operational parameters e.g. db_host, db_port. You want to have them differently in local dev (per user files, not in git) and in production (injected through k8s config maps).

Aren't this a common use case? How would you suggest to approach it?

Thanks a bunch,
Zaar

[jbasko]

In terms of physical implementation environment variables is my first choice. If it's not practical (I use direnv with .envrc files in my local environment), any json or yaml file will do. The key though is to abstract away the details of loading values - for the user (yourself) the source of the values shouldn't matter.

That's why I wrote configmanager and have been writing similar utilities again and again. Whatever you choose (standard library's configparser, json.load, yaml.load), if you are an experienced developer, sooner or later you will introduce a layer that abstracts the loading of values away and in the end you will have some class like Env or Profile or XyzServiceConfig etc., instance of which will have attributes that match the values you are interested in: config.db_host, config.max_connections etc.

Then you put all the loading logic either in initialiser or some factory methods and the user of this class is totally unaware of where the values come from.

[haizaar]

Then you put all the loading logic either in initialiser or some factory methods and the user of this class is totally unaware of where the values come from.

Indeed! But you still need to write that loading logic! May be you moved over to simplified configuration somehow...

For me, I just have a in-house tool that has a subset of configmanager features, but is build in quite an ad_hoc manner. Today I decided to give it a good polish, then stopped to look around and found configmanager that implements exactly what I was about to write and more (in a good way). So, despite your recommendation, I guess I'll take it - I think it would be less overall effort to work on potential issues with configmanager than to write my own code that does the same thing and the fix bugs there :)

Just to clarify - you don't recommend it because of a design philosophy, not because of the code stability/quality, right?

[kdeldycke]

After reading this thread, I ended up recreating my own config loader for Click. It is available as a standalone package: click-extra.

It support TOML file loading for the moment but I am considering adding YAML.

[kdeldycke]

Since my last comment I added JSON, YAML, INI and XML configuration support to click-extra.