Design: ENV vars to override config

[aqw]

Onyo configuration should be temporarily setable via environmental variables. For example:

ONYO_CONFIG_CORE.EDITOR=vim onyo edit [...]

Everything is uppercase. All config names are preceded with ONYO_CONFIG_ and then follow with the exact same dot-notation config name as is used in onyo config.

Open questions:

• should the envvar override values in .onyo/config? This was my initial idea, but apparently it's the opposite of what git does (normally; some configs are an exception and allow the envvar to override).

[TobiasKadelka]

should the envvar override values in .onyo/config? This was my initial idea, but apparently it's the opposite of what git does (normally; some configs are an exception and allow the envvar to override).

That's crazy. It seems so obvious to me that the terminal should overwrite the config values that I can't believe git does not do that. Now I feel like we should first read up on their reasoning.

Maybe there is something like configuring editor = /usr/bin/nano locally should not be overwritten because a script which has ONYO_CONFIG_CORE.EDITOR=vim onyo edit [...] would then break?

---

Besides that "open question" I agree, this would be a cool feature. (even though it has lower priority to me than some other issues we currently discuss)

[bpoldrack]

Generally agree. However, I'm pretty sure that not all shells, if any, support periods in env vars. So, I'd follow datalad here and translate the periods to underscores. What's questionable is the prefix, though.

We have configs onyo.some.other. Following the suggested approach would be ONYO_CONFIG_ONYO_SOME_OTHER. That's a little verbose. All our configs start with onyo anyway. I don't think we need to provide an override for git configs by special env vars. Whoever wants that, knows git and can use its env vars (I don't buy that env vars not overriding is generally true for git - but we don't need to discuss that here.) That would mean, one can directly translate the config names to env var names: onyo.a.b -> ONYO_A_B. Much simpler, IMO. Only caveat: If all we have is the ONYO_ namespace, we can't use env vars for anything else. But I have a hard time imagining what else we would want to use env vars for, that shouldn't also be a config.

Lastly, I'd suggest the combination with introducing an onyo -c config.name switch. Just like git, this another way of overriding per call. For the case where a git env var doesn't do that, there's a solution (onyo -c core.editor=vim edit ...).

Environment variable takes precedence over stored config, and - I think - -c over env var?

[aqw]

Broad agreement with what you wrote.

However, I'm pretty sure that not all shells, if any, support periods in env vars.

Hah. You're right. A . is not a valid char for shell vars. :facepalm:

I don't buy that env vars not overriding is generally true for git - but we don't need to discuss that here

I was also surprised, but read it in a few places, though non canonical. I agree it's a side-point, but if I find a resource I will share.

Environment variable takes precedence over stored config, and - I think - -c over env var?

Oooh. Yeah, I don't know...

I agree that .onyo/config (et al) should be at the bottom.

-c does feel more explicit than an environment variable, which may be set in a login script...

And with that in mind, yeah, I think it should be the following:

onyo -c > ENVVAR > onyo config