DEV Community

loading...

Discussion on: A clean way to pass configs in a Go application

Collapse
chinglinwen profile image
chinglin

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?

Collapse
ilyakaznacheev profile image
Ilya Kaznacheev Author

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.

Collapse
chinglinwen profile image
chinglin

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

Collapse
ilyakaznacheev profile image
Ilya Kaznacheev Author

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).