Allow users to set properties via OS environment variables

[paxtonhare]

Provide a mechanism for letting users set properties to environment variables.

I created this as a workaround: https://github.com/marklogic/roxy/wiki/Using-Operating-System-Environment-Variables-in-properties

But I'd like to see it become an included feature for .properties. Perhaps something like:

user=env['app_username']
password=env['app_password']

maybe even (note the lack of quotes):

user=env[app_username]
password=env[app_password]

You could even allow other variables to get subbed-in:

export app_username=admin
export app_local_username=admin2

app-name=my-app
user=${app-name}-env[app_username]   # would become user=my-app-admin
password=env[app_${environment}_password] # would become user=admin2

[grtjn]

How about something a little more dense like:

user=%{MYENVUSER}

[rlouapre]

How about using the same syntax used for passing properties from command line?
Property value ml.password will be replaced by the environment variable ml.password

[paxtonhare]

I like the idea of always checking the environment variables of the same
name before using the value from the properties files.

pseudo code would be:

property[key] = env[key] || @properties[key]

The only downside I see to this approach is that you could drive yourself
mad if you accidentally set the property in the shell and forget you did
it. Then you keep changing the value in the .properties file and wonder why
it's not being picked up.

[grtjn]

Sounds interesting. I like the idea of prefixing with ml. We could also extend ml local info to provide more feedback, like where value came from, env, env.prop, build or defaults..

[rlouapre]

Could logger.debug provide detail on where the property value comes from?
Also to clarify property can be defined from environment variable, command line argument and property file.
Should the priority be the same listed above?
That would be a great improvement for CI integration.

[grtjn]

debug versus info, nice idea. Yes, I think debug should mention name of properties file (local.properties/build.properties), or ENV or cmd-line. Command-line works strongest, then ENV, then properties in existing order.

Not sure what you mean by priority?

[rlouapre]

Assuming ml.property1 is set as environment variable, command line argument and file properties which has the highest priority.

[grtjn]

I have actually implemented something for this. Unfortunately, ml.xxx is not a valid variable name, so I had to use ml_xxx instead. But everywhere a properties file is loaded using the load_properties function, values for defined properties are overridden by same-name env variable (ml.user -> ml_user). This way command-line overrides work strongest. And you don't need separate syntax for using env vars from within properties files or ml-config, just pre-declare them in one of the properties files..

./ml local info | grep ml.user ==> ml.user: admin
ml_user=env ./ml local info | grep ml.user ==> ml.user: env
ml_user=env ./ml local info --ml.user=param | grep ml.user ==> ml.user: param

The info command doesn't tell where values were coming from yet. We can always decide later to add that if people really need that..

[grtjn]

Fixed in dev