Support for .env files

[ptink]

• I have searched the issues of this repo and believe that this is not a duplicate.

Issue

First off I really like poetry- I'd actually only recently migrated over to pipenv but I already see the advantages of poetry and would ideally like to use it full time.

I primarily work with Django and other web frameworks that can require a large amount of configuration which- when following 12 factor app practices- involves lots of environment variables that necessitates the use of a .env file.

Is there a possibility of adding in .env file support, specifically for poetry's run command so that the resulting command runs both in the virtualenv and with the environment as configured in the .env file?

[sdispater]

I don't think this is in the scope of Poetry.

Since Poetry is not configured via environment variables there are no reasons for it to load a .env file.

If the libraries you use need it, it's their responsability to load it not Poetry's.

[jacebrowning]

I've always liked using direnv for this. It supports loading .env files automatically.

[ptink]

@jacebrowning direnv isn't cross platform unfortunately. When the environments I worked in were solely on Linux I used direnv in conjunction with vex to achieve functionality similar to pipenv run <command> for example. This workflow doesn't work on Windows which was a major reason for my discovery and subsequent switch to pipenv when I realised it could do the same thing.

I agree that poetry doesn't need .env files for it's own configuration (although it's not a bad idea to use them to allow for directory-specific configuration that may differ from the globals defined in the config file) but I don't think it's out of scope for poetry to load .env files for run and shell when you consider that they are both attempts to isolate the given command in an environment that is specific to the current project.

I understand the concerns about scope creep, especially when the PR adds a new dependency. If you're exclusively writing libraries then this particular use case may not occur very often but for 12 factor apps it's pretty vital to have tooling to support it- and it always seemed like a neat solution to me to have the virtualenvironment be in control of it.

[AlJohri]

I've used https://github.com/jezdez/envdir/ for something similar.

it uses an envs folder instead of a .env file.

https://github.com/toddbluhm/env-cmd is also good if you want to stick to the .env file

it should be simple to use an alias that chains the two commands together

[ptink]

Again, I'm aware other external libraries exist that do this but I'm of the belief that this particular functionality would be useful to have included in Poetry itself. It's a vital part of tooling required for 12 factor apps and it would be helpful to people who are moving towards adopting an environment variables-based approach in their project to have support for it in the tooling they (ideally) are already using for their project. The goal being to reduce the barrier to entry for managing python projects so that we don't end up back in the "oh just install pip and virtualenv and virtualenvwrapper, easy!" mess that we're finally moving away from :)

If @sdispater would prefer that this isn't included within the project then my next solution would be to modify the entry-point to my Django applications so that they read the required env vars using python-dotenv. That's obviously less ideal but still better than relying on more external libraries that drop in and out of maintanence.

[Pluckerpluck]

I'd like to voice my support of this. The ability to automatically load .env files when running poetry run or poetry shell makes a lot of sense to me. (There's a reason pipenv does it)

Environmental variables are generally designed to be read from the shell (i.e. not a file) and so it makes sense for this to be within the scope of poetry, given that it creates a sub shell for isolation.

In short: Environmental variables should be part of Poetry's virtual environment.

[pmav99]

What's the problem with having direnv or aactivator or whatever handle this? To be honest, I also use them to handle the virtualenv creation/activation but that's purely optional. I prefer those dedicated projects, because I can also use them on non-python projects (e.g. to set up credentials for databases, environmental variables etc).

I can understand that it could be convenient to have this implemented in poetry itself, but it feels like it is kind of out of scope + there are projects that do exactly this thing and IMHO quite well so.

[pawamoy]

Could be a candidate for a plugin once they are a thing.

[Pluckerpluck]

@pmav99 Me being on Windows is really the biggest problem here.

@pawamoy As long as plugins could work with this type of thing (likely, but never guaranteed) I'd be fine with that.

[pmav99]

The fact that setting up an environment on Widows is hard does not answer why setting up the environment becomes poetry's responsibility though.

[Pluckerpluck]

@pmav99 I've already stated why I think setting up the environment in poetry's virtual environment makes sense. Poetry uses virtual environments to provide isolation. That's the point of virtual environments. How does it not makes sense that within that environment, environmental variables could be set?

This is particularly true for the poetry shell command which literally spawns a sub shell for you to access directly. For example, I regularly use poetry shell followed by setting FLASK_ENV to development in order to run my HTTP endpoints locally while debugging.

You simply stated why I couldn't use other pieces of software, and I answered. Windows is not supported by them. Poetry, on the other hand, claims to support Windows.

[ptink]

If the upcoming plugin system has hooks for injecting env vars then I agree that this would be an ideal candidate for a plugin

[ekhaydarov]

oh boy, coming from pipenv, which has an array of issues, poetry seems to have issues which pipenv has solved. why dont they just marry already

[sdispater]

Like I said above this is beyond the scope of Poetry so I am closing this issue.