cannot call app.run() from custom cli command

[miguelgrinberg]

Expected Behavior

There are situations in which you may want to implement a custom application runner. Two examples that I can think of are running the application under the Werkzeug profiler, and starting the application in a background thread to perform integration tests against it.

In these situations, most people would want to create a custom CLI command that calls app.run() to start the application after applying any necessary changes, such as enabling profiling, etc.

Example bug.py:

from flask import Flask

app = Flask(__name__)

@app.cli.command()
def custom_run():
    app.run()

What I expect with the above example is that running flask custom_run starts the development web server.

Actual Behavior

(venv) $ FLASK_APP=bug.py flask custom_run
/home/miguel/bug.py:7: Warning: Silently ignoring app.run() because the application is run from the flask command line executable.  Consider putting app.run() behind an if __name__ == "__main__" guard to silence this warning.

I think this warning should only appear when app.run() is called from the global scope of the main module. This can be determined from the number of frames in the call stack. The warning should be issued only if the call stack has two frames, but should not if there are more than two. Thoughts?

[miguelgrinberg]

FYI, I included a fix for this problem in #2781.

[sktzofrenic]

I've found a solution to this that works in my case. I needed to have a separate flask app as a click command which failed when upgrading to 1.0.

In my situation, I created autoapp.py and autoapp_proxy.py and changed out the environment variable for FLASK_APP=<app> depending on which version I needed to run so that flask run would pull the correct app.

I think I prefer the fix in your PR but wanted to throw this out there as an option that may work for some people's use case.

[davidism]

I think the most I want to do here is to move the FLASK_RUN_FROM_CLI var to only be set from the flask run command, and not by any flask command. That way, a custom run command can decide to call app.run() successfully. However, that comes with the standard issue with app.run(), that calling it necessarily imports it, which means any errors during import will crash the command instead of being handled by the debugger and reloader.

[davidism]

Actually, I don't think it would be good to only set that from flask run. Presumably, an unguarded call shouldn't interrupt any command, not only the run command. You wouldn't want a server accidentally starting when you called flask shell or flask db upgrade.

Disabling this check is a pretty uncommon requirement, it would only come up if you're writing a custom run command that works by calling app.run, as opposed to make_server, etc. If you really want to, I think it's reasonable to unset the env var in the command.

def custom_run():
    del os.environ["FLASK_RUN_FROM_CLI"]
    app.run()

I'm doing some other work on the CLI, I might think of a more "official" way to turn off this check. For now the env var is fine, even though it's not really a public API. Just pay attention to our changelog if unsetting it is something your library depends on.