I'm a beginner to Flask and I ran into some errors. about how I did not provide the Flask_APP environment variable:
Error: Could not locate a Flask application. You did not provide the "FLASK_APP" environment variable, and a "wsgi.py" or "app.py" module was not found in the current directory.
I have this error with flask when I try and run my flask code. My code was working at first but then when I tried running it again it had this problem. I searched everywhere for help but I could only find ones about powershell. I'm currently using Ubuntu. Thank you!
In order to run a flask app using the flask command in the terminal, you need to set an environment variable in that terminal. For example, if your app is created in my_app.py, then you need to execute the following in your terminal:
export FLASK_APP=my_app.py
If you restart the terminal at any point you will need to re-export this variable.
You can check if it is set in your current terminal using:
echo $FLASK_APP
which will show nothing if unset or my_app.py if set as above.
Once in your project directory run the command below will solve your problem
flask --app app.py db init
Where app.py is your flask application file name.
Related
This question already has answers here:
How to run a flask application?
(6 answers)
Closed 3 years ago.
The following ways allows me to launch the Flask server.
Option 1:
set FLASK_APP = app.py
flask run
Option 2:
set FLASK_APP = app.py
python -m flask run
Option 3:
python app.py
What is the difference between using either of this?
$ python app.py
This is the simplest, standard way of calling the Python interpreter to run any Python script. It is not specific to Flask. The app.py may or may not have a if __name__ == "__main__" block (see What does if __name__ == "__main__": do?), but if you are going to do this for Flask, it is required to have __main__ method that calls app.run().
From the Flask docs:
The alternative way to start the application is through the
Flask.run() method. This will immediately launch a local server
exactly the same way the flask script does.
Example:
if __name__ == '__main__':
app.run()
The docs also state why even though this works, it is not recommended:
This works well for the common case but it does not work well for
development which is why from Flask 0.11 onwards the flask method is
recommended. The reason for this is that due to how the reload
mechanism works there are some bizarre side-effects (like executing
certain code twice, sometimes crashing without message or dying when a
syntax or import error happens).
This way is also problematic if you need to modify run configurations (ex. port) depending on the host environment. For example, you need to use port 5500 instead of the default 5000 when running on a certain machine. You can of course do this with os.environ and app.run(port=5500), but it's going to be "messy" modifying the code based on environment-related configs that are unrelated to the code.
That is why we have the second way, the flask command line tool.
from flask import Flask
app = Flask(__name__)
#app.route('/')
def hello_world():
return 'Hello, World!'
$ set FLASK_APP=app.py
$ flask run --port=5500
You can now maintain your code to be independent of any external environment configurations. Aside from that, the flask CLI tool has a lot of other options for configuration and debugging, such as enabling/disabling DEBUG mode, listing routes (flask routes), and getting env vars from .env files.
Notice also that your app does not have to explicitly call app.run and __name__ now isn't going to be __main__. This is helpful for cases where your app is just part of a bigger package and/or it needs to be run from some other directory. See the Larger Applications section of the Flask docs.
Finally, we have the third way:
$ python -m flask run
This is another standard way of running Python scripts. It is also not specific to Flask. From the docs:
When called with -m module-name, the given module is located on the
Python module path and executed as a script.
This means flask will be searched from the invoked python module search path. This is particularly useful when your environment has multiple versions of Python and you want to make sure you are using the correct Python version and env with Flask. It can also be useful when you have multiple Flask installations for multiple projects. It explicitly sets which Python interpreter to use to call the flask CLI tool.
$ python3.8 -m flask --version
Python 3.8.10
Flask 1.1.2
Werkzeug 1.0.1
$ python3.8 -m flask run
$ python3.7 -m flask --version
Python 3.7.4
Flask 1.1.1
Werkzeug 0.16.0
$ python3.7 -m flask run
$ python -m flask --version
Python 2.7.16
Flask 1.0.3
Werkzeug 0.14.1
$ python -m flask run
flask run
This one looks for an executable (called flask) on your PATH, the first one executes with a parameter run, which will make the flask helper run the application by calling FLASK_APP.
python -m flask run
This one looks for an executable called python on your PATH, the first one executes receiving -m as argument, which is supposed to run a module (flask) and then pass the parameter run to it.
The key difference here, is that as it executes the first found executable on PATH, you can run a totally different Flask from the first one. You can also run a different python version's Flask.
python app.py
This calls the first python executable on PATH, and passes app.py as argument. It will make python run the app.py script, which may or may not have app.run() (This is what starts Flask).
If you don't have anything inside app.py, it won't call Flask's server.
I have a python module, it works fine, it uses pandas as one of its dependencies.
I added a Flask application in the middle with a rest service which has a service that imports and runs the very same module.
module = importlib.import_module('modules.' + script.module, package=__package__)
Both the python module and the flask app run with the same virtualenv activated, in which pandas is installed.
-BUT- when running this through the flask app, it throws an exception:
ImportError: No module named pandas
Tried to run the module without calling it from Flask and it works just fine...
=== UPDATE ===
I don't know why Flask is running on python 2 even though I'm running it with a virtualenv of python 3 activated.
This is the script I'm using to start my Flask app:
#!/bin/bash
export FLASK_APP=run.py
export FLASK_DEBUG=1
flask run
I'd appreciate any help
Thanks a lot
I've fixed it.
I haven't installed Flask within the virtualenv I was running, so I think that's why Flask was running on a different python version.
So I installed flask on my virtualenv and now it works.
I am developing a web app and i want to have obviously local environment.
However I need to setup local env configs in my .env file and when I run python manage.py runserver it doesn't seem to load my env file, although heroku local does load it. Just to make sure I understand whats happening, id love to know what is the difference.
I build my flask app, it requires external files through the runtime.
when I build the app, meaning I run > gunicorn app:app (the app startup file is called app.py but that didn't bother). It runs awesomely.
Now when I decided to make a sort of shell script to execute it (actually to make a couple of dependencies and environment checking but for the sake of simplifying, I created startup.sh in the same directory as app.py and it contains only the following instruction unquoted: "gunicorn app:app"), it just throws errors.
and this is the last one ...
Please help..
yep just as I guessed, it should be run within the script inside a virtualenv so that it will execute python 3 :)
I have a Flask web app that I'm trying to run on webfaction. The application runs fine through Gunicorn and the test server, but I can't get it to work with Apache.
I've narrowed it down to the lack of access to environment variables. If I run the app with Gunicorn, the environment variables are correct and the app works correctly. If I run the app with Apache, I can't access the environment variables.
Note: the environment variables are set correctly and exported correctly, so that's not where the issue lies. Again, it works perfectly, only not with Apache.
Any ideas on how to resolve this?