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.
Ilya is a Cloud Native Architect, he is an expert in the world of cloud technologies and distributed systems. He helps SMBs to earn more and spend less with proper cloud decisions.
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.
Ilya is a Cloud Native Architect, he is an expert in the world of cloud technologies and distributed systems. He helps SMBs to earn more and spend less with proper cloud decisions.
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).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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).