-
-
Notifications
You must be signed in to change notification settings - Fork 316
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
[RFC] Add support for docker-style _FILE environment variables #189
Labels
enhancement
New feature or request
Comments
@apollo13 have you done any work on this? |
Nope
…On Thu, Jan 24, 2019, at 23:50, Víðir Valberg Guðmundsson wrote:
@apollo13 <https://github.com/apollo13> have you done any work on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#189 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE-i9yjC8sljIEShn500PdomQsDpU4Pks5vGjjCgaJpZM4VGa3H>.
|
tkdchen
pushed a commit
to tkdchen/django-environ
that referenced
this issue
Oct 6, 2019
Hopefully this saves time for new users of django-configuration (like myself), who "just needed" to lazily evaluate a string inside a dictionary. This doubles as an example for `RAVEN_CONFIG` which was the whole reason I was here in the first place... The actual problem I faced was that a setting remains of type `values.Value` when nested inside a dictionary. Which results in a weird issues like this: ``` 2018-02-24T20:59:26.125208+00:00 app[web.1]: Traceback (most recent call last): 2018-02-24T20:59:26.125364+00:00 app[web.1]: self.client.http_context(self.get_http_context(environ)) 2018-02-24T20:59:26.125215+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/raven/middleware.py", line 98, in __call__ 2018-02-24T20:59:26.125368+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/raven/contrib/django/models.py", line 54, in <lambda> 2018-02-24T20:59:26.125482+00:00 app[web.1]: __getattr__ = lambda x, o: getattr(get_client(), o) 2018-02-24T20:59:26.125486+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/raven/contrib/django/models.py", line 134, in get_client 2018-02-24T20:59:26.125613+00:00 app[web.1]: instance = Client(**options) 2018-02-24T20:59:26.125618+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/raven/contrib/django/client.py", line 147, in __init__ 2018-02-24T20:59:26.125769+00:00 app[web.1]: Client.__init__(self, *args, **kwargs) 2018-02-24T20:59:26.125771+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/raven/base.py", line 171, in __init__ 2018-02-24T20:59:26.125927+00:00 app[web.1]: self.set_dsn(dsn, transport) 2018-02-24T20:59:26.125929+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/raven/base.py", line 251, in set_dsn 2018-02-24T20:59:26.126063+00:00 app[web.1]: if dsn not in self._transport_cache: 2018-02-24T20:59:26.126076+00:00 app[web.1]: TypeError: unhashable type: 'Value' ```
SmileyChris
added a commit
to SmileyChris/django-environ
that referenced
this issue
Sep 13, 2021
This is resolved in |
mehdy
pushed a commit
to mehdy/django-environ
that referenced
this issue
Oct 5, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'd like to add support for docker-style
_FILE
environment variables. What this would mean basically is the following:Take this line as an example:
This will make
environ
look for aDATABASE_URL
and use that. I'd like to extend it to first look forDATABASE_URL_FILE
and if that variable exists and is set read the file it points to and use that instead ofDATABASE_URL
.The idea here is that stuff like docker swarm secrets are injected as files into your container and I'd need an easy way to reference those. You can find more information about it at https://hub.docker.com/r/_/postgres/ (scroll down to
Docker Secrets
). Note that while I am referring solely to docker here, the same holds true for any other system which injects secrets as files and not environment variables.Backwards compatibility wise there should be no issue;
would try
ASD_FILE_FILE
and not readASD_FILE
as file directly...If you think this is a good idea I'll happily supply a PR; if you are need more convincing please also tell me :)
The text was updated successfully, but these errors were encountered: