per-environment named keys

[buhman]

expand_keyring_var currently calls get_password two ways (renamed labels for clarity):

• USE_KEYRING: pair.section, pair.key
• USE_KEYRING[name]: name, None

Ignoring the part where get_password's calling convention should be optional keyword arguments and not jank conditional variable reordering, hubble should have support for named keyring variables with implicit section->keyring environment mappings.

---

The use-case is basically this:

[hubble]
OS_PASSWORD=USE_KEYRING["product-password"]

[lon]
OS_PASSWORD=USE_KEYRING["product-password-lon"]

Instead of having two key names, product-password and product-password-lon, I should be able to create a product-password in the global keyring environment, and a product-password in the lon keyring environment.

This allows the configuration to be condensed to just:

[hubble]
OS_PASSWORD=<new-use-keyring-syntax>["product-password"]

---

As you can see, this is probably a most easily implemented as backwards-incompatible change.

[buhman]

The exact new syntax also probably depends on the result of #10. I think it makes more sense to have a template engine handle use_keyring injection than to make up some clumsy syntax.

[thrawn01]

In your example It's unclear when a key name is only confined to the environment namespace or the global namespace. in any case, giving your key name it's on explicit namespace should not be difficult and is much more explicit. USE_KEYRING["lon.product-password"] is very clear what the user wants without any confusing magic.

[thrawn01]

When we do this for hubble 2.0 perhaps we could add some identifier to indicate this is a locally scoped variable. I've updated the milestone to 2.0

[buhman]

USE_KEYRING["lon.product-password"] is very clear what the user wants without any confusing magic.

However, it's not composable. You would still need to use interpolation, like: USE_KEYRING["${section}.product-password"].

Also, with that syntax, it might not be clear if . should be interpreted as a label separator or a literal dot in the key name.

[thrawn01]

After thinking about this for a bit, I think it's ok to have the composable feature for those who understand/need this functionality, and for those who prefer the explicit method the old method should still work.

[buhman]

jank conditional variable reordering

On re-reading this, I was reminded of a language feature that neither go nor python has: multiple dispatch