Allow changing environment variable per field

[pschichtel]

From the documentation it seems the the ENV property source only supports loading values from variables that encode the path of the property in its object tree.

I have an existing application that uses a lot of environment variables and I want to migrate to hoplite (from spring) and I'd prefer not to change all of the variables.

One workaround I see would be to use a preprocessor to replace ENV vars in properties that are defined in a yaml file.

[pschichtel]

I now see why things are the way they are. I still think this would be great, but I doubt it's feasible

[sksamuel]

Can you give me an example of what you mean?

[pschichtel]

I have a simple configuration object like this:

data class Config(val someDuration: Duration)

In order to load that config value from the env var DURATION (for compatibility reasons or whatever), I have to use e.g. a yaml config like this:

someDuration: ${DURATION}

I know this is a bit of a constructed example, but imagine more complex config object with many nested objects.

what I'd like to do what be something like:

data class Config(@FromEnv("DURATION") val someDuration: Duration)

Having the config file for this seems redundant, because I'm only ever using it as a proxy for the env values. I guess my use-case is not really a good fit for hoplite.

[sksamuel]

Theres an EnvPropertySource you can register that provides values directly from env vars like you want. There's no need then to have the file mappings.

[pschichtel]

Yes, but with that I don't have control over the specific environment variables to be used.

[sksamuel]

So what about an EnvVarMappedPropertySource that allows you to specify a mapping between env names and config names ?
There's also @ConfigAlias which you can put on your config fields to map back to the env names.

[pschichtel]

So what about an EnvVarMappedPropertySource that allows you to specify a mapping between env names and config names ?

Yes, that sounds like what I'm looking for.

There's also @ConfigAlias which you can put on your config fields to map back to the env names.

I've seen that, but that only renames a local property name, right?

So if I have:

data class SomeOptions(@ConfigAlias("ENV_VAL") val string: String)
data class Config(val options: SomeOptions)

that the @ConfigAlias would change options__string to options__ENV_VAL, right? I want it to look for the env var ENV_VAL without any prefix, no matter how deep the property is nested in the tree.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pschichtel]

The stale bot might be the most annoying thing on github...

[rocketraman]

If you are migrating from Spring,then #414 should solve your problem automatically.

[pschichtel]

@rocketraman nope, we haven't used spring's automatic env names at all, all our environment variables are custom named.

[rocketraman]

@pschichtel Ok yeah I understand now -- the problem is that hoplite does not have at the moment any notion of a "global" config value accessible at any level in the configuration node tree. @sksamuel what do you think about nodes having a reference back to the root node? That way the DataClassDecoder could try to resolve a parameter at the current level of the tree, but fall back to resolving it using a value in the root node e.g. an env var.

[pschichtel]

I'm not sure how that would look like in practice