Add support to override os.environ to allow for better envfile-chaining and other advanced use #352
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are some closed tickets regarding loading multiple env-files, like #73 #246 #257, most issues which can be implemented using
dotenv_values
as described in comments and READMEThere are still some cases that I keep running in to that would be solved by this pull request, mostly regarding preparing environments/doing health checks for docker deployment and docker-compose-files, to be used as env-parameter to subprocess-calls for tools without envfile-support or serialized to some YAML-file to be used by other tools.
One example is when auto-deploying feature-branches to test environments which is composed by some server-wide settings
/etc/env.server
, one.env.[productname]
for base product settings and one.env.[deployment]
which contain some optional final overrides for that specific featurebranch/customer/user provided settings, all coming from different sources.Right now you have to normalize newlines and create a
StringIO(server_settings + deployment_settings + product_settings + deployment_settings)
to have interpolation working correctly, and also clear the os.environ in the local process during thedotenv_values-call
to avoid conflicting options in the running enviroment. If there are some values that are generated in the program you also have to serialize them before use.By allowing to replace os.environ with a custom dict you can use
dotenv_values
with a clean environment for safe use both with or without threads, provide fallback/override values from python and chain multiple .env-files and still have functioning interpolation between multiple env-files. It's also possible to compare the resulting values without mocking os.environ in unit tests.Example usage as added to README:
I started working on an implementation for chained loading in the cli and the helper methods, but felt that it was too out of scope for this project and that these additions alone would open up for project specific implementations without monkeypatching.