Pipenv: Use different .env file for run/shell with --dev

Created on 22 Oct 2017  Â·  2Comments  Â·  Source: pypa/pipenv

Since the --dev flag is used to mark out packages that are for development environments, why not use it with run/shell for the same purpose? Perhaps a .env.dev that gets loaded after .env if pipenv run --dev or pipenv shell --dev is run.

The reason for this is that Django has a DJANGO_SETTINGS_MODULE environment variable, and I think many who follow this Taskbuster Tutorial would use it to set DEBUG = True at some point. The tutorial still uses virtualenvs to switch between dev and production.

(Not sure if this is more of a best practices problem or a feature suggestion...)

Most helpful comment

@randName Not a big fan of this one. Check out this resource on some best practices for environment variables: https://12factor.net/config

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle.

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

I like using this tool: https://github.com/jezdez/envdir. The final command would look something like: envdir envs/local pipenv run python app.py.

For django specifically, I have an alias dal (local) and dap (prod) which is equal to envdir envs/prod pipenv run django-admin. This way I can run dap migrate or dal runserver.

Hope this helps!

All 2 comments

@randName Not a big fan of this one. Check out this resource on some best practices for environment variables: https://12factor.net/config

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle.

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

I like using this tool: https://github.com/jezdez/envdir. The final command would look something like: envdir envs/local pipenv run python app.py.

For django specifically, I have an alias dal (local) and dap (prod) which is equal to envdir envs/prod pipenv run django-admin. This way I can run dap migrate or dal runserver.

Hope this helps!

I think @AlJohri summed it up. Thanks for the input @randName!

Was this page helpful?
0 / 5 - 0 ratings