When using python-dotenv or similar systems, I often find myself writing instructions for other developers that look like this:
pip install -r requirements.txt
cp default.env .env
python entrypoint.py
This is because I want to exclude .env from version control, since I expect individual devs to mess with it. But I want to supply a ready-to-go env file for developers.
But I don't like this. Ideally, I don't want the developers to even have to think about .env at all if it's not relevant to them. For example, the developer might be part of our frontend team and she doesn't know/care about how we configure backend services, she just needs a copy of this running on her dev box to do her actual job. Or maybe the person who's working on this is already in the middle of learning several other things, and the last thing they need is the additional cognitive overhead of having to think about how .env works.
The above instructions are sufficiently stereotypical that they could easily be implemented into the package, provided that nobody was concerned about the additional complexity, and or considered this too out-of-scope for the package.
Here's what we do: add one additional parameter to load_dotenv and class DotEnv called init_dotenv_path which defaults to None. Now, if we attempt to load the file, if dotenv_path is not undefined, but it is a file path which does not exist, and if init_dotenv_path is defined and is a file path which does exist, then we copy init_dotenv_path to dotenv_path and try to load the file again.
Now as a user, I would just write e.g.
load_dotenv(init_dotenv_path='default.env')
And now a developer doesn't even need to know about env files to run the project.
It might also be a good idea for the logger to emit "copying default.env to .env" if this code path was used (possibly only if set to verbose).
When using
python-dotenvor similar systems, I often find myself writing instructions for other developers that look like this:This is because I want to exclude
.envfrom version control, since I expect individual devs to mess with it. But I want to supply a ready-to-go env file for developers.But I don't like this. Ideally, I don't want the developers to even have to think about
.envat all if it's not relevant to them. For example, the developer might be part of our frontend team and she doesn't know/care about how we configure backend services, she just needs a copy of this running on her dev box to do her actual job. Or maybe the person who's working on this is already in the middle of learning several other things, and the last thing they need is the additional cognitive overhead of having to think about how.envworks.The above instructions are sufficiently stereotypical that they could easily be implemented into the package, provided that nobody was concerned about the additional complexity, and or considered this too out-of-scope for the package.
Here's what we do: add one additional parameter to
load_dotenvandclass DotEnvcalledinit_dotenv_pathwhich defaults toNone. Now, if we attempt to load the file, ifdotenv_pathis not undefined, but it is a file path which does not exist, and ifinit_dotenv_pathis defined and is a file path which does exist, then we copyinit_dotenv_pathtodotenv_pathand try to load the file again.Now as a user, I would just write e.g.
And now a developer doesn't even need to know about env files to run the project.
It might also be a good idea for the logger to emit
"copying default.env to .env"if this code path was used (possibly only if set to verbose).