-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for env var substitutions in env.str and env.dict and other composite types #164
Comments
Reviewing the docs and the open PRs, perhaps this feature can be merged or replace Proxied Variables. Proxied variables are a special case of this substitution. Anyway, I think it shouldn't be enabled by default, as this can be a security issue (For example someone sets: |
Interesting idea. I'm not opposed to this in principle, esp if it doesn't add too much complexity. I agree that it could possibly replace proxied variables. Would you like to put up a PR sketch? |
Done, check #168 . I wasn't sure about proxied variables, perhaps a path for deprecation might be raising DeprecationWarning for a few versions and later remove |
Great, thanks! I won't be able to review the PR in depth for the next few days--work and life commitments all coming fast--but I'll do my best not to lose track of it. |
Sure, no problem. Tell if you need I do any fix to the PR. Thank you for
this awesome project
El mar., 1 sep. 2020 12:57, Steven Loria <[email protected]>
escribió:
… Great, thanks! I won't be able to review the PR in depth for the next few
days--work and life commitments all coming fast--but I'll do my best not to
lose track of it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#164 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA6743MQYE6AYIV5BTGA4DSDUKVRANCNFSM4PTVCLWA>
.
|
I found some use cases where doing env var substitution inside the VALUE of another envvar it's very helpful.
For example:
And being able to read the variable like this would be awesome:
The main use case is when you have the user/pass as individuals secrets (perhaps handled by an operator like https://github.com/zalando/postgres-operator) but you need a URI with parts that don't need to be secret.
Another use case is a workaround when composite variables like dict become too complex. For example:
If you do
env.dict("INIT_KARGS")
you getValueError: too many values to unpack
because of the "=" in the second value. So in this case you can do:We can use a syntax like this for the references to the environments variables: ${VARIABLE[:-default][:ttype]}. For example
${YEAR:-2020:tint}
. (the :- is how you specify defaults in bash, the third :t parameter is for specifying the type is not str).Here is the code I'm using in my project (a bit ugly):
If you agree with this new feature, I can try to do a PR. The new feature will be activated only if explicitly using
substitute_envs=True
as parameter.The text was updated successfully, but these errors were encountered: