Context: I am writing a medium sized flask application (10-15 views), and in the process, I am hoping to organize the code in a manner that will make it easily maintainable and extensible (not a monolithic file as most Flask applications are).
The structure of the application mimics the documentation as follows:
/AwesomeHackings
/ENV
/AwesomeHackings
/models
/static
/templates
/__init__.py
/awesome.py
/awesome.cfg
/Procfile
/README.MD
/requirements.txt
/run.py
Problem: I am unable to get foreman to work with a flask application which is not named 'app'. I would love to have run.py be the entry point to my application.
I am using gunicorn + gevent, and my current Procfile contains:
web: gunicorn -w 2 -b 0.0.0.0:$PORT -k gevent app:run
I have been using run.py
to test the application:
from AwesomeHackings import awesome
awesome.app.run(debug=True)
Thus I assumed I could simply substitute run
for app
in the Procfile, but when executing foreman start
, gunicorn fails with meaningless verbiage about modules.
I found the solution in Django's documentation. The main parameter of gunicorn is module:
gunicorn [OPTIONS] APP_MODULE
Where APP_MODULE
is of the pattern MODULE_NAME:VARIABLE_NAME
While it seemed logical for the syntax to be a keyword argument app:someIdentifier, as all of the tutorials use a module named app
, it is in fact not the case. The correct argument for my situation was run:app
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With