"flask run" should accept a command line option for FLASK_APP

[jab]

Currently, flask run can be controlled via one set of environment variables and a different set of command line options. In some cases there is overlap (e.g. FLASK_RUN_PORT and --port), but in other cases there is not.

The most problematic example is the flask app object. The only way to specify this explicitly is via the FLASK_APP environment variable; there is no command line option you can pass flask run to specify this instead.

(This is especially asymmetrical when using Flask with e.g. gunicorn, where the wsgi app must be passed via required positional command line argument.)

Would you accept a patch to allow passing a command line option for FLASK_APP? Being forced to use an environment variable to set this value is less than ideal, as it forces writing this important value out-of-band into a shared mutable global namespace (the environment), rather than being able to pass it directly in-band to flask run.

[ThiefMaster]

Not possible due to how click works. the app must be accessible at an earlier stage (since it can also add other flask subdommands). IIRC in an early version it was possible to use flask [--debug] [--app NAME] <subcommand> and @mitsuhiko then removed it because of issues with click.

[davidism]

We had --app and --debug options initially, but they turned out to cause issues in the interaction between the app, the CLI, and the dev server. See #2292 for the last time I decided to check if it was possible.

You're welcome to work on this, but be prepared for the implementation to be much harder than you expect. It probably needs to be addressed in Click first.

[jab]

Thanks for the background info @davidism!

@mitsuhiko, do you feel this is still blocked on pallets/click#590 (as you originally mentioned a couple years ago in #1820)?

[jab]

Closing pending reply from @mitsuhiko (in which case it may be reopened) or more like WONTFIX?

While we’re at it, is supporting an --env option (as an alternative to the FLASK_ENV environment variable) worth considering? The fewer options that can only be configured via env vars (which are global, shared mutable state that is invisibly inherited by child processes) the better.

[davidism]

FLASK_ENV is deliberately not an option on the command line or app.run.

I closed this because it's been discussed before with no change in outcome, and I don't find it particularly useful to keep a tracking issue for it. The behavior has been this way for at least a couple years now, I don't think it matters one way or another at this point.

Again, you're welcome to work on it, if you manage to solve it I will gladly review a PR. Yes, it's still blocked on behavior in Click, so figuring out what to fix there is the first step.

[jab]

you're welcome to work on it, if you manage to solve it I will gladly review a PR. Yes, it's still blocked on behavior in Click, so figuring out what to fix there is the first step.

Thanks! Hope to get more time to look into this soon. 🤞

[jab]

FLASK_ENV is deliberately not an option on the command line or app.run.

(Interesting! Just spent some time trying to find if this is written down somewhere and only found #2264 (comment), which is outdated and no longer true. Curious to understand this more. Thanks again for your consideration.)