You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The load_local_env_vars module seems unnecessary and is weird that we call that function in prod (it's a no-op). It creates a situation where local code branch is different from prod code based on environment variables.
One idea
If we rename local.env to dotenv then it will automatically load.
Pros:
This will also help remove code branches that differ between local and prod systems.
This will allow local developers to have their personal config changes without accidentally committing it and messing up other people's configs. Shared configs can still go in something like .env.template.
Cons:
The con is that new config changes will need to be communicated to devs so they can pull new config changes from .env.template.
Another possibility for running on local host machine would be to let developers rely on tools that appropriately set environment variables in the shell. direnv is a good tool for this. We can have developers install direnv and then have an .envrc file that sources the local.env file.
The load_local_env_vars module seems unnecessary and is weird that we call that function in prod (it's a no-op). It creates a situation where local code branch is different from prod code based on environment variables.
One idea
If we rename
local.env
to dotenv then it will automatically load.Pros:
.env.template
.Cons:
More context
Also see this PR discussion https://github.com/navapbc/template-application-flask/pull/138/files#r1105922982
The text was updated successfully, but these errors were encountered: