Replies: 1 comment 1 reply
-
Hey @cswrd ,
I believe that this it is not "intentional" in the sense to prohibit other uses, but that it just wasn't a relevant use case when it was implemented. How you deal with this depends on your preference and constrains, I really don't have any experience on that to share. But there are some options, such as the ones you presented (which seems reasonable).
I guess it could work if its setup properly, like with some naming convention for different apps or something like that. But again, I don't have experience to share about this.
That's possible to implement. What I think could be done on top of the current implementation is to add some hook right after dynaconf-specific config is appplied, so users have a chance to override those. Not sure if that could be achieved only with the current hooks implementation, my memory is not very fresh on that, but I think we can't. Maybe this generalization could be addressed more elegantly in dynaconf 4. |
Beta Was this translation helpful? Give feedback.
-
There are many settings that can be controlled via
_FOR_DYNACONF
suffixed environment variables. As far as I understood, all applications using dynaconf might use them. Hence, one could not use application specific environments variables with that suffix. How to deal with it / what is it the intentional use of it?Actually share those global settings between apps, e.g. use a shared root_path for all settings of all applications on the file system?
Add another environment management layer that dynamically sets the environment just the individual app?
Beta Was this translation helpful? Give feedback.
All reactions