this is a repost from my blog at kaznacheev.me. I welcome new readers and will be happy to discuss what I'm writing about
There are many concurr...
For further actions, you may consider blocking this person and/or reporting abuse
Nice article Ilya, but you forgot survey-based configuration, just kidding :P But to be honest I had the same issue two years ago and created a small package which respects: flags, files and survey-flow, you can play with it or take some ideas from: github.com/kataras/pkg/tree/master...
Nice repo! I'm developing a lib that simplifies configuration composition right now, and this can be very helpful.
I highly recommend Peter Bourgon's best practices on configuring Go applications.
Very interesting, thanks!
Don't forget to "defer f.Close()" the file!
Nice technique but for production I recommend using some digest methods for the passwords because are exposed being as clear text.
For example?
One method could be digesting the input password with a hardcoded salt resulting the final password for the server (initial password can't be used without the second salt even you know the encription method and can't be reversed).
Other method, encrypt password with a hardcoded salt, store encrypted in the configuration file and decrypt at load with the same salt as in the following example.
thepolyglotdeveloper.com/2018/02/e...
Interesting, thanks
One thing I don't like a seperate config package or config structure is that it bond to specific application makes go package(depend on config) re-using is difficult.
What do you think?
Usually, the configuration is attached to the executable file, i.e. main.go.
Another part of the project (it may be a package or a set of packages, internal packages or whatever) should receive the related configuration via its own public interface (factories, functions, etc.).
In productive projects, I create the main config structure, which includes substructures for different parts of the program, because it's useful. But for libraries and open-source projects, it's ok to define config structure inside each package or library to decrease coupling.
I've just found this package to be what I like flag first
Not that complex(like viper), still using flag( explicit ), but provide env parse and config file loading.
github.com/peterbourgon/ff
I've designed a tiny library for config management: cleanenv.
It uses regular structures with tags, which means, that you can read flags or whatever into this structure and then override it with values from config and environment (or conversely).
idea to replace yaml pkg with pkg.go.dev/sigs.k8s.io/yaml ? with only one json tag
web.archive.org/web/20190603050330...