Expand environment variables when reading from file about cleanenv HOT 7 CLOSED

An interesting feature, but I don't think that it has so many real use-cases.

Normally configuration variables provided to the application as-is from some environment - CI/CD pipeline, k8s pod, cloud environment (like Heroku), etc. That means, that the value will be either prepared before it is passed as config or processed after in the application.

For example, Postgres connection string, which is made of a dozen config variables. It usually is either a whole string or a set of parameters (user, password, db name, host, port, etc.). And the app has to know how to join them into a valid connection string.

If we will implement this feature, then one of our configuration sources will have extra behavior - to parse several config values in one variable. There are a couple of cons:

• other sources cannot do the same, that means, you cant override config values anymore;
• we use tags to set up sources, but in this case, it means you have to initialize the variable with some value instead, so
  • where you should define them?
  • how to handle them?
  • what with other sources? Should they override them or try to emulate the same logic?

So I don't think, that we need that feature as a part of the library. If you want something like that, you can use a setter or updater interfaces to override default logic with your own for certain fields or the whole structure.

from cleanenv.

I will leave this issue open for some time to discuss that topic and then close it.

from cleanenv.

Hi,
the most common use case for this feature is every environment which passes configurations, secrets and other stuff as a json in one env-variable.
This is at least done in CloudFoundry and as far as i know also in AWS.

If i would use the custom setter if would need to have for every property one if see this correctly. This doesn't sound like a good option.

If i would implement the translation for postgres as you mentioned in the code this would make it really restricted to the environment and will not be very flexible for multiple environments where this environments may be named differently.

I also don't get your point for "other sources". Do you mean for example when using json or something else as configuration file?
Because you can also use this behaviour in json and other formats as well.

Also such a feature is common to be part of a configuration library as you can see in uber's config (https://github.com/uber-go/config/blob/master/expand.go)

Maybe it would be enough to have an option to pass something like a global hook when loading configuration. Like the setter/updater you have mentioned above but more like a post-processing function for everything which is loaded.

Best regards

from cleanenv.

Further i've just discovered that the custom setter will not be invoked when the configuration is loaded from YAML.
Is this intended or is it a bug?

Thanks

from cleanenv.

Looks like a bug, I will check. Thanks!

from cleanenv.

Looks that #75 is the same bug

from cleanenv.

Will close this one prior to the issue with a better bug explanation.

As for environment variables expansion support - no such planes yet, I'm trying to keep the library as simple as possible.

But I'm thinking about a more flexible extension solution, so users will be able to cover more complex cases on their own.

from cleanenv.