When I try to update the __init__.py file in Flask, it doesn't show the changes in the server, but when I edit home.html it works fine.
app/__init__.py
import os
from flask import Flask, render_template
from werkzeug.contrib.fixers import ProxyFix
app = Flask(__name__)
#app.route('/')
def home():
return render_template('home.html')
app.wsgi_app = ProxyFix(app.wsgi_app)
app.debug = bool(os.environ.get('PRODUCTION'))
if __name__ == '__main__':
app.run()
Any tips?
We solved the problem in comments but I will add solution here if someone else has a similar problem.
For development environment add debug=True argument to your app
app.run(debug=True)
If your development environment works on an application server, then you should look for autoreload option. In uWSGI there is py-auto-reload for example.
For released, stable environment you should restart your application server.
For example in uWSGI
There are several ways to make uWSGI gracefully restart.
# using kill to send the signal
kill -HUP `cat /tmp/project-master.pid`
# or the convenience option --reload
uwsgi --reload /tmp/project-master.pid
# or if uwsgi was started with touch-reload=/tmp/somefile
touch /tmp/somefile
More: http://uwsgi-docs.readthedocs.io/en/latest/Management.html#reloading-the-server
Warning: if you combine application and web server, uWSGI and Nginx for example, then restarting Nginx won't reload your application code. Focus on the application server.
Related
We followed this guide on setting up Flask on IIS https://medium.com/#dpralay07/deploy-a-python-flask-application-in-iis-server-and-run-on-machine-ip-address-ddb81df8edf3 and it works well but when we do flask run from VS code we get the following
PS J:\Apps\prod> flask run
* Serving Flask app 'wsgi.py' (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
* Running on http://127.0.0.1:5000 (Press CTRL+C to quit)
About the development server line and the production WSGI server line - is this purely because we set it up in IIS? Should we have followed a different route than what was in that guide we followed?
Everything else I'm seeing seems to be only relevant to *nix based systems i.e using Gunicorn
Thanks
The guide you followed, though captured quite a few screen shots and contained a lot of information, does not describe the recommended approach from Microsoft, because Python via FastCGI on IIS is no longer supported as quoted from here,
We recommend using HttpPlatform to configure your apps, as the WFastCGI project is no longer maintained.
To get up-to-date information on this setup, you can refer to my blog post. I list the key points below to make a standalone answer.
Preparation
Prepare a folder such as C:\flask-test, and create app.py as
from flask import Flask
def create_app():
app = Flask(__name__)
#app.route("/")
def hello_world():
return "<p>Hello, World!</p>"
return app
and wsgi.py
from app import create_app
application = create_app()
Then install both flask and waitress,
pip install flask waitress
And test that both flask run and waitress-serve work,
PS C:\flask-test> ~\AppData\Local\Programs\Python\Python310\python.exe -m flask run
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
* Running on http://127.0.0.1:5000 (Press CTRL+C to quit)
PS C:\flask-test> ~\AppData\Local\Programs\Python\Python310\python.exe -m waitress --port 9000 wsgi:application
INFO:waitress:Serving on http://0.0.0.0:9000
IIS Integration
Add a web.config file in this folder to enable HttpPlatformHandler,
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" requireAccess="Script" />
</handlers>
<httpPlatform stdoutLogEnabled="true" stdoutLogFile=".\python.log" startupTimeLimit="20" processPath="C:\Users\lextudio\AppData\Local\Programs\Python\Python310\python.exe" arguments="-m waitress --port %HTTP_PLATFORM_PORT% wsgi:application">
</httpPlatform>
</system.webServer>
</configuration>
Then on IIS you can create a new site to point to C:\flask-test.
More details can be found in my blog post, especially on troubleshooting.
Prepare a folder such as C:\flask-test, and create app.py as
from flask import Flask
from gevent.pywsgi import WSGIServer
app = Flask(__name__)
#app.route('/api', methods=['GET'])
def index():
return "Hello, World!"
if __name__ == '__main__':
# Debug/Development
# app.run(debug=True, host="0.0.0.0", port="5000")
# Production
http_server = WSGIServer(('', 5000), app)
http_server.serve_forever()
Note: Install gevent using pip install gevent
You can use waitress. It's a production WSGI server.
from waitress import serve
serve(app, host="0.0.0.0", port=8080)
It's a drop-in replacement to your classic app.run().
I want to know the correct way to start a flask application. The docs show two different commands:
$ flask -a sample run
and
$ python3.4 sample.py
produce the same result and run the application correctly.
What is the difference between the two and which should be used to run a Flask application?
The flask command is a CLI for interacting with Flask apps. The docs describe how to use CLI commands and add custom commands. The flask run command is the preferred way to start the development server.
Never use this command to deploy publicly, use a production WSGI server such as Gunicorn, uWSGI, Waitress, or mod_wsgi.
As of Flask 2.2, use the --app option to point the command at your app. It can point to an import name or file name. It will automatically detect an app instance or an app factory called create_app. Use the --debug option to run in debug mode with the debugger and reloader.
$ flask --app sample --debug run
Prior to Flask 2.2, the FLASK_APP and FLASK_ENV=development environment variables were used instead. FLASK_APP and FLASK_DEBUG=1 can still be used in place of the CLI options above.
$ export FLASK_APP=sample
$ export FLASK_ENV=development
$ flask run
On Windows CMD, use set instead of export.
> set FLASK_APP=sample
For PowerShell, use $env:.
> $env:FLASK_APP = "sample"
The python sample.py command runs a Python file and sets __name__ == "__main__". If the main block calls app.run(), it will run the development server. If you use an app factory, you could also instantiate an app instance at this point.
if __name__ == "__main__":
app = create_app()
app.run(debug=True)
Both these commands ultimately start the Werkzeug development server, which as the name implies starts a simple HTTP server that should only be used during development. You should prefer using the flask run command over the app.run().
Latest documentation has the following example assuming you want to run hello.py(using .py file extension is optional):
Unix, Linux, macOS, etc.:
$ export FLASK_APP=hello
$ flask run
Windows:
> set FLASK_APP=hello
> flask run
you just need to run this command
python app.py
(app.py is your desire flask file)
but make sure your .py file has the following flask settings(related to port and host)
from flask import Flask, request
from flask_restful import Resource, Api
import sys
import os
app = Flask(__name__)
api = Api(app)
port = 5100
if sys.argv.__len__() > 1:
port = sys.argv[1]
print("Api running on port : {} ".format(port))
class topic_tags(Resource):
def get(self):
return {'hello': 'world world'}
api.add_resource(topic_tags, '/')
if __name__ == '__main__':
app.run(host="0.0.0.0", port=port)
The very simples automatic way without exporting anything is using python app.py see the example here
from flask import (
Flask,
jsonify
)
# Function that create the app
def create_app(test_config=None ):
# create and configure the app
app = Flask(__name__)
# Simple route
#app.route('/')
def hello_world():
return jsonify({
"status": "success",
"message": "Hello World!"
})
return app # do not forget to return the app
APP = create_app()
if __name__ == '__main__':
# APP.run(host='0.0.0.0', port=5000, debug=True)
APP.run(debug=True)
For Linux/Unix/MacOS :-
export FLASK_APP = sample.py
flask run
For Windows :-
python sample.py
OR
set FLASK_APP = sample.py
flask run
You can also run a flask application this way while being explicit about activating the DEBUG mode.
FLASK_APP=app.py FLASK_DEBUG=true flask run
I know for a fact that Flask, in debug mode, will detect changes to .py source code files and will reload them when new requests come in.
I used to see this in my app all the time. Change a little text in an #app.route decoration section in my views.py file, and I could see the changes in the browser upon refresh.
But all of a sudden (can't remember what changed), this doesn't seem to work anymore.
Q: Where am I going wrong?
I am running on a OSX 10.9 system with a VENV setup using Python 2.7. I use foreman start in my project root to start it up.
App structure is like this:
[Project Root]
+-[app]
| +-__init__.py
| +- views.py
| +- ...some other files...
+-[venv]
+- config.py
+- Procfile
+- run.py
The files look like this:
# Procfile
web: gunicorn --log-level=DEBUG run:app
# config.py
contains some app specific configuration information.
# run.py
from app import app
if __name__ == "__main__":
app.run(debug = True, port = 5000)
# __init__.py
from flask import Flask
from flask.ext.login import LoginManager
from flask.ext.sqlalchemy import SQLAlchemy
from flask.ext.mail import Mail
import os
app = Flask(__name__)
app.config.from_object('config')
db = SQLAlchemy(app)
#mail sending
mail = Mail(app)
lm = LoginManager()
lm.init_app(app)
lm.session_protection = "strong"
from app import views, models
# app/views.py
#app.route('/start-scep')
def start_scep():
startMessage = '''\
<html>
<header>
<style>
body { margin:40px 40px;font-family:Helvetica;}
h1 { font-size:40px; }
p { font-size:30px; }
a { text-decoration:none; }
</style>
</header>
<p>Some text</p>
</body>
</html>\
'''
response = make_response(startMessage)
response.headers['Content-Type'] = "text/html"
print response.headers
return response
The issue here, as stated in other answers, is that it looks like you moved from python run.py to foreman start, or you changed your Procfile from
# Procfile
web: python run.py
to
# Procfile
web: gunicorn --log-level=DEBUG run:app
When you run foreman start, it simply runs the commands that you've specified in the Procfile. (I'm going to guess you're working with Heroku, but even if not, this is nice because it will mimic what's going to run on your server/Heroku dyno/whatever.)
So now, when you run gunicorn --log-level=DEBUG run:app (via foreman start) you are now running your application with gunicorn rather than the built in webserver that comes with Flask. The run:app argument tells gunicorn to look in run.py for a Flask instance named app, import it, and run it. This is where it get's fun: since the run.py is being imported, __name__ == '__main__' is False (see more on that here), and so app.run(debug = True, port = 5000) is never called.
This is what you want (at least in a setting that's available publicly) because the webserver that's built into Flask that's used when app.run() is called has some pretty serious security vulnerabilities. The --log-level=DEBUG may also be a bit deceiving since it uses the word "DEBUG" but it's only telling gunicorn which logging statements to print and which to ignore (check out the Python docs on logging.)
The solution is to run python run.py when running the app locally and working/debugging on it, and only run foreman start when you want to mimic a production environment. Also, since gunicorn only needs to import the app object, you could remove some ambiguity and change your Procfile to
# Procfile
web: gunicorn --log-level=DEBUG app:app
You could also look into Flask Script which has a built in command python manage.py runserver that runs the built in Flask webserver in debug mode.
The solution was to stop using foreman start as stated in the comments and directly execute python run.py.
This way, the app.run method with the debug=True and use_reloader=True configuration parameters take effect.
Sample Application where app is our application and this application had been saved in the file start.py:
from flask import Flask
app = Flask(__name__)
#app.route('/')
def hallo():
return 'Hello World, this is really cool... that rocks... LOL'
now we start the application from the shell with the flag --reload
gunicorn -w 1 -b 127.0.0.1:3032 start:app --reload
and gunicorn reloads the application at the moment the file has changed automaticly. No need to change anything at all.
if you'd love to run this application in the background add the flag -D
gunicorn -D -w 1 -b 127.0.0.1:3032 start:app --reload
-D Demon mode
-w number of workers
-b address and port
start (start.py) :app - application
--reload gunicorns file monitoring
Look at the settings file:
http://docs.gunicorn.org/en/latest/settings.html
all options and flags are mentioned there. Have fun!
based on this structure: http://flask.pocoo.org/docs/patterns/packages/
I also tried this post: Deploying Flask app to Heroku
I am having trouble getting this to work on heroku. I usually get the PORT does not set within 60 seconds error. I have read other SO posts and just can't figure out if my project structure is wrong or my procfile. I tried other ports than 5000 as well.
Here is my current project structure:
/myapplication
Procfile
runserver.py
/applicationfolder
__init__.py
views.py
Here is my Procfile
web: python runserver.py $PORT
Here is my runserver.py
from applicationfolder import app
app.run()
if __name__ == '__main__':
import os
port = int(os.environ.get('PORT', 5000))
app.run(host='0.0.0.0', port=port)
Here is my init.py
import os
from flask import Flask
from flask import render_template, jsonify, request
app = Flask(__name__)
app.config.from_object('config')
import applicationfolder.views
From there views.py runs.
This works locally with foreman start and python runserver.py, but does not work with heroku. I have tried many things with PORT but port doesn't seem to set even with a different PORT than 5000. I think it has something to do with my project structure.
The app.run() was in there twice, which as you noted is what's screwing things up. The app.run() invokes a simply pure-python development server so that you can easily run and/or debug your script.
By invoking it at the module level (right under your import in runserver.py), you were effectively trying to start the development server as the python code was loaded, and then when it went to run it when invoked from the Procfile, the development server was already in flight, having been starting with it's defaults (latest version of Flask is pulling relevant defaults from the SERVER_NAME environment variable). By having it in both places, you were trying to invoke that method twice.
You basically want either the straight up module load (in which case, kill off the code under "if name ...", or you use the code when invoking under main, in which case don't start the service at module load time.
I have a Flask app that runs fine on local, but when I push to Heroku I get the error message:
* Running on http://127.0.0.1:5000/
[INFO] Starting gunicorn 18.0
[ERROR] Connection in use: ('0.0.0.0', 8163)
I tried the solution in this question, where gunicorn and werkzeug were fighting with each other, but adding a __name__ == "__main__" block to my master application file (run.py) didn't solve my error.
This SO post suggested making sure my processes were all cleaned up. I did that but it still didn't work, so I actually deleted my entire heroku app and repushed and it still gives the same error.
My run.py file looks like:
#!pl_env/bin/python
from app import app
if __name__ == "__main__":
app.run(debug=True, port=33507)
# [33507 is the Flask port on Heroku]
And my Procfile is:
web: gunicorn run:app
The __init__.py file in app is:
from flask import Flask
import os
from flask.ext.login import LoginManager
app = Flask(__name__)
app.config.from_object('config')
lm = LoginManager()
lm.init_app(app)
lm.login_view = 'login'
from app import views
Views has the meaty logic of the app in it, but I don't think there's anything in there that would mess with gunicorn. Here's the views.py imports just in case:
from flask import Flask, render_template, flash, redirect
from flask.ext.login import login_required, login_user
from app import app, lm
from forms import LoginForm
I am definitely at a loss as to where to look now to figure out this connection error. Any thoughts on why it seems to think I'm already using 0.0.0.0?
Thank you
Monica
EDIT: I ran the app locally using foreman start and it worked cleanly in 0.0.0.0:5000, so I think I'm having a Heroku problem
EDIT2: I intentionally broke my view flow -- made an internal infinite reference -- and pushed it to see what would happen. I got the expected error logs, undid it, and pushed the rollback, and now it's working. I have absolutely no idea why that should work, except maybe that breaking it in an expected way flushed my gunicorn connections. If anyone has any explanations for this mystery, I would love them.
app.run(host='0.0.0.0')
might do the trick as explained here