Added .env support #2164

mitsuhiko · 2017-01-29T19:30:31Z

This will instruct Flask to read .env files and then to load the
environment variables from there. Additionally it automatically
changes the working directory to the path the .env is contained in.

flask/cli.py

@@ -120,6 +120,47 @@ def find_default_import_path():
    return app


+def find_dotenv():
+    here = os.getcwd()
+    while 1:


flask/cli.py

+            if not line or line[:1] == '#' or '=' not in line:
+                continue
+            key, value = line.split('=', 1)
+            _set_env(key, value)


flask/cli.py

+            if not line or line[:1] == '#' or '=' not in line:
+                continue
+            key, value = line.split('=', 1)
+            _set_env(key, value)


flask/cli.py

+    with open(path, 'rb') as f:
+        for line in f:
+            line = line.strip()
+            if not line or line[:1] == '#' or '=' not in line:


untitaker

LGTM though I really want tests for this.

flask/cli.py

+    with open(path, 'rb') as f:
+        for line in f:
+            line = line.strip()
+            if not line or line[:1] == '#' or '=' not in line:


mitsuhiko · 2017-01-29T19:43:23Z

Yeah, tests will come if we like this behavior.

untitaker · 2017-01-29T19:58:59Z

In case it gets lost: #2164 (comment)

RonnyPfannschmidt · 2017-01-29T19:59:47Z

isnt there a library for env files? imho flask shouldnt reimplement

mitsuhiko · 2017-01-29T20:00:19Z

@RonnyPfannschmidt i'm not going to pull in a one liner dependency here.

@untitaker the behavior here is consistent with other libraries that implement .env loading.

docs/cli.rst

+
+    FLASK_APP=/path/to/hello.py
+    FLASK_DEBUG=1
+


mitsuhiko · 2017-01-29T20:57:53Z

So maybe we put the conversation back to where this started: the goal was to make it easier during development to refer to the current Flask app. I do not see this as a feature for production. However let's see if we can figure out the production case as well.

How does one refer to their own app in production without exporting env variables?

miguelgrinberg · 2017-01-29T22:07:16Z

@mitsuhiko I agree, good idea to pull back a bit.

I think referring to the app instance should work in the same way for development and production, I don't see why the methods should differ, since the app instance is the same in all cases. And there is also the complication of app factories, which are not friendly to FLASK_APP (#2027).

What I do, is define a wsgi.py file for each of my projects. I started adopting this as a convention, so I can have a hardcoded FLASK_APP=wsgi.app set in my .profile file and switch from app to app without worries. Would you consider implementing one or more sensible defaults for FLASK_APP? I think wsgi.application and wsgi.app are fairly common and could be defaults.

jeffwidman · 2017-01-30T04:42:12Z

I've also commonly seen .env files used to store secrets, and managed via Ansible Vault or similar.

CHANGES

@@ -11,6 +11,9 @@ Major release, unreleased
 - Make `app.run()` into a noop if a Flask application is run from the
  development server on the command line.  This avoids some behavior that
  was confusing to debug for newcomers.
+- The `flask` command line tool now loads a `.env` file when it discovers
+  one.  When it finds one it will change into that folder before starting


davidism · 2017-01-30T14:03:11Z

How does one refer to their own app in production without exporting env variables?

I do it by not using the flask command directly. Instead, I install an entry point to the project's own FlaskGroup, configured appropriately, and expect the project to be installed in the env both in development and production.

cli = FlaskGroup(create_app=create_app)

setup(
    ...,
    entry_points={
        'console_scripts': [
            'myapp=myapp.cli:cli.main',
        ],
    },
    ...,
)

FLASK_DEBUG=1 myapp run

davidism · 2017-01-30T14:04:26Z

One option for making this play nicer with the factory pattern is to allow making a call in the FLASK_APP var. Gunicorn and uWSGI allow this. gunicorn myapp.app:create_app(where='dev')

nickjj · 2017-01-30T19:38:43Z

@mitsuhiko

How does one refer to their own app in production without exporting env variables?

Is this a valid question? Because you could also say "how does one refer to their own app in production without creating an instance/settings.py file", and then it becomes the same thing.

At the end of the day, this file needs to be on the production box for the app to be usable.

Personally, I use Docker and it has mechanisms for supplying an .env file of my choosing, then it makes those env variables available to the Flask app with no extra dirty work.

Without Docker, I would likely drop an environment file in /etc/default/fooapp which is the defaco-standard place on a Debian system to write out app-level environment variables. Then I would source that file in whatever init system I use.

In other words, in both development and production this env file would be available to the Flask app.

If this feature does end up being implemented, please let us configure the .env filename.

I would much prefer to use env variables instead of config/instance files because it plays much nicer when trying to scale applications on infrastructures that let you define clusters of servers, but then can define env variables in a central area (outside of each individual host), and then they become available to all hosts without worrying about the logistics of getting an env file on the system.

This could be done now of course, but it kind of goes against the norm which is to use config/instance based config files instead of env variables.

justanr · 2017-01-31T03:47:51Z

If I'm understanding this correctly, this would only read the .env when executed from the CLI, correct? That seems like it setting developers up for mistakes, I can see the bug reports and SO questions now: "Flask loads my .env file when I run the development server, but not when executed from uWSGI"

If this was going to be added, I'd rather see it implemented into either the Flask class or config class to at least be consistent between server options.

greyli · 2017-04-07T13:04:37Z

I did it by adding this into virtual environment's activate script, the variable will be set automatically when the virtual environment was activated. No multiple application crashing, no new file.

For example:
Unix Bash: venv/bin/activate:

FLASK_APP=foo.py
export FLASK_APP

Windows CMD.exe: venv\Scripts\activate.bat:

set "FLASK_APP=foo.py" 
:END

untitaker · 2017-04-07T13:05:34Z

I don't recommend editing activate scripts.

greyli · 2017-04-07T13:08:35Z

@untitaker More detail?

untitaker · 2017-04-07T13:09:52Z

I already elaborated in the PR you sent. You are editing random files which will get overwritten if you recreate the virtualenv (e.g. because it grew too big, or because a Python upgrade trashed it).

davidism · 2017-04-07T13:10:32Z

How about adding an entry point in setup.py to tell the flask command where the app is, similar to how we can add extra commands? Since we're encouraging the use of setup.py anyway, might as well take advantage. Not sure how we would handle multiple packages with the entry point though, if that ever comes up.

untitaker · 2017-04-07T13:17:36Z

See #2234 (comment)

davidism · 2017-04-07T14:17:10Z

I'm leaning on the side of rejecting this. I agree that it would cause confusion, and we already have a documented way to set the env when working locally.

untitaker · 2017-04-07T16:43:50Z

Hmm, I'm not sure if we have discussed this enough yet. I only merged #2234 because it enhanced the docs for existing recommendations. I would actually prefer a file separate from the virtualenv activate script, for the additional reason that you would have to edit it for multiple shells.

…

On Fri, Apr 07, 2017 at 09:39:15AM -0700, David Lord wrote: Closed #2164. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2164 (comment)

mitsuhiko added 2 commits January 29, 2017 20:24

Ignore .env file

a1039ac

Added .env support

14b3ed2

mitsuhiko added the in progress label Jan 29, 2017

ThiefMaster reviewed Jan 29, 2017

View reviewed changes

flask/cli.py

with open(path, 'rb') as f:

for line in f:

line = line.strip()

if not line or line[:1] == '#' or '=' not in line:

This comment was marked as off-topic.

Sign in to view

This comment was marked as off-topic.

Sign in to view

untitaker reviewed Jan 29, 2017

View reviewed changes

flask/cli.py

with open(path, 'rb') as f:

for line in f:

line = line.strip()

if not line or line[:1] == '#' or '=' not in line:

This comment was marked as off-topic.

Sign in to view

Add support for unquoting strings in the .env file

88ce968

miguelgrinberg reviewed Jan 29, 2017

View reviewed changes

JordanP reviewed Jan 30, 2017

View reviewed changes

davidism closed this Apr 7, 2017

untitaker removed the in progress label Apr 7, 2017

davidism mentioned this pull request Jun 14, 2017

Add .env support, take 2 #2375

Closed

davidism mentioned this pull request Jul 15, 2017

Add .env support #2416

Merged

davidism deleted the feature/dotenv branch July 16, 2017 20:55

github-actions bot locked as resolved and limited conversation to collaborators Nov 14, 2020

Added .env support #2164

Added .env support #2164

Conversation

mitsuhiko commented Jan 29, 2017

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

untitaker left a comment

Choose a reason for hiding this comment

This comment was marked as off-topic.

mitsuhiko commented Jan 29, 2017

untitaker commented Jan 29, 2017

RonnyPfannschmidt commented Jan 29, 2017

mitsuhiko commented Jan 29, 2017

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

mitsuhiko commented Jan 29, 2017

miguelgrinberg commented Jan 29, 2017 • edited Loading

jeffwidman commented Jan 30, 2017

This comment was marked as off-topic.

This comment was marked as off-topic.

davidism commented Jan 30, 2017 • edited Loading

davidism commented Jan 30, 2017 • edited Loading

nickjj commented Jan 30, 2017 • edited Loading

justanr commented Jan 31, 2017

greyli commented Apr 7, 2017

untitaker commented Apr 7, 2017

greyli commented Apr 7, 2017

untitaker commented Apr 7, 2017

davidism commented Apr 7, 2017 • edited Loading

untitaker commented Apr 7, 2017

davidism commented Apr 7, 2017

untitaker commented Apr 7, 2017 via email

miguelgrinberg commented Jan 29, 2017 •

edited

Loading

davidism commented Jan 30, 2017 •

edited

Loading

davidism commented Jan 30, 2017 •

edited

Loading

nickjj commented Jan 30, 2017 •

edited

Loading

davidism commented Apr 7, 2017 •

edited

Loading