Develop Reference

Uvicorn --reload using WatchFiles is not working for FastAPI in Docker container

I am developing a FastAPI app. It is running on Uvicorn in a Docker container using docker-compose.
I want to include some files other than *.py to trigger the auto reload while in development.
According to the docs Uvicorn needs the optional dependency WatchFiles installed to be able to use the --reload-include flag, which would enable me to include other file types to trigger a reload. However, when WatchFiles is installed (with Uvicorn confirming by printing this info at start up: Started reloader process [1] using WatchFiles) no auto reloads happen at all. Mind you, this is independent of changes to the run command, with or without the include flag.
Without WatchFiles installed, Uvicorn's default auto reload works as intended for just *.py files.
What I've got
This is the Dockerfile:
FROM python:3.10
WORKDIR /tmp
RUN pip install --upgrade pip
COPY requirements.txt .
RUN pip install --no-cache-dir --upgrade -r requirements.txt
WORKDIR /code
CMD ["uvicorn", "package.main:app", "--host", "0.0.0.0", "--port", "80", "--reload"]
This is the docker-compose.yml:
version: "3.9"
services:
fastapi-dev:
image: myimagename:${TAG:-latest}
build:
context: .
volumes:
- ./src:/code
- ./static:/static
- ./templates:/templates
restart: on-failure
ports:
- "${HTTP_PORT:-8080}:80"
(I need a docker-compose file because of some services required later on.)
The most basic FastAPI app:
from fastapi import FastAPI, HTTPException
app = FastAPI()
#app.get('/')
async def index():
raise HTTPException(418)
Mind you, this is probably of no concern as the problem does not seem to be related to FastAPI.
requirements.txt:
fastapi~=0.85
pydantic[email]~=1.10.2
validators~=0.20.0
uvicorn~=0.18
watchfiles
python-decouple==3.6
python-multipart
pyotp~=2.7
wheezy.template~=3.1
How did I try to resolve this issue?
I tried using command: uvicorn package.main:app --host 0.0.0.0 --port 80 --reload in docker-compose.yml instead of CMD [...] in the Dockerfile, which unsurprisingly changed nothing.
I created a file watch.py to test if WatchFiles works:
from watchfiles import watch
for changes in watch('/code', force_polling=True):
print(changes)
And…in fact it does work. Running it from the container in Docker CLI prints all the changes made. (python -m watch) And btw it works just as fine async/using asyncio. So it is probably nothing to do with the file system/share/mount within Docker.
So…
How do I fix it? What is wrong with Uvicorn(?) I need to check for other file types e.g. *.html in /templates. Do I have to get WatchFiles to work or are there other ways? If I do, how?

I just had the same problem and the problem is with WatchFiles.
In the watchfiles documentation it is understood that the detection relies on file system notifications, and I think that via docker its events are not launched when using a volume.
Notify will fall back to file polling if it can't use file system notifications
So you have to tell watchfiles to force the polling, that's what you did in your test python script with the parameter force_polling and that's why it works:
for changes in watch('/code', force_polling=True):
Fortunately in the documentation we are given the possibility to force the polling via an environment variable.
Add this environment variable to your docker-compose.yml and auto-reload will work:
services:
fastapi-dev:
image: myimagename:${TAG:-latest}
build:
context: .
volumes:
- ./src:/code
- ./static:/static
- ./templates:/templates
restart: on-failure
ports:
- "${HTTP_PORT:-8080}:80"
environment:
- WATCHFILES_FORCE_POLLING=true

Newrelic for FastApi

I use this command in docker compose:
newrelic-admin run-program gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8000
but after running, I encountered with following error:
(14/ThreadPoolExecutor-0_0) newrelic.core.trace_cache ERROR - Runtime instrumentation error. An active trace already exists in the cache on thread_id 281472746332640. Report this issue to New Relic support.
How can I fix it?!
Thanks

I initialized newrelic.ini config in main.py. It works and the errors were fixed:
import newrelic.agent
newrelic.agent.initialize('newrelic.ini')

Heroku: bash: waitress-serve: command not found

I have a REST API exposed with Falcon and Waitress. It works fine in my local environment and want to publish it in Heroku.
To start the API, in my Procfile I have the following:
web: waitress-serve --port=$PORT app:api
And I can't see it correctly in the Free Dynos resources.
But when I deploy in Heroku, I get the following error message:
bash: waitress-serve: command not found
I'm using the following Buildpack:
https://github.com/teamupstart/conda-buildpack
In my root folder, I have conda-requirements.txt with waitress==1.3.0
Am I missing anything?

My fix for this was that I had not updated my requirements.txt file with my most recent installs. Do that, git push, and it might work.
I'll add also that my Procfile is this:
web: waitress-serve --port=$PORT --call myapp:create_app

Can't get heroku procfile

I'm trying to build up a deep-learning-based facebook chatbot (using Python). I'm trying to deploy it on Heroku firstly, but as I'm using the command web: gunicorn echoserver:app the terminal says web: command not found. Howevere, I've installed gunicorn already.

This is because you are typing web:, which is not a command line interface (CLI) command.
If you've installed gunicorn, then the command (from the CLI) is gunicorn. Something like, for instance
gunicorn echoserver:app
I suppose it's also possible that you have a Windows machine. gunicorn does not work on Windows, so you would need to use something like waitress. With waitress, you would type web: on a Windows machine, so that it would be something like
web: waitress-serve echoserver:app

Note that the procfile is literally a file you place in your repository. The contents of the procfile should contain the command you want Heroku to run to start your server.
So in the root directory of your repo, you should have a Procfile (named exactly that with no file extension) with the following contents:
web: gunicorn echoserver:app
The first part (web:) is just used to tell Heroku which dyno to run the second part (the command) on. So Heroku will only run the command on web dynos and not on background dynos.
More info here: https://devcenter.heroku.com/articles/procfile

Couldn't find that process type, Heroku

I'm trying to deploy a simple python bot on Heroku but I get the error
couldn't find that process type
When I try to scale the dynos. I already made a procfile and it looks like this:
web: gunicorn dep:app, where "dep" is the name of my python code
What could be the reason?

This may happen if your procfile is misspelt, such as "procfile" or "ProcFile" etc. The file name should be "Procfile" (with a capital P).
sometimes changing the file name is not anough, because git wouldn't spot the change. I had to delete the Procfile completely, then commit the change, than add it again with the right name, and then commit that again:
remove your procfile
git commit
add a new procfile with the exact name "Procfile"
commit again
git push heroku master (or main - new heroku projects now uses main)
should work!

Make Sure Procfile should not have any extension like .txt
otherwise this will be the error
remote: -----> Discovering process types
remote: Procfile declares types -> (none)
To create file without extension type following in cmd
notepad Procfile.
Now add web: gunicorn dep:app and save
Now when you will git push heroku master the above lines will be like
remote: -----> Discovering process types
remote: Procfile declares types -> web
And the error is gone when you will run
C:\Users\Super-Singh\PycharmProjects\URLShortener>heroku ps:scale web=1
Scaling dynos... done, now running web at 1:Free

Ensure that the Procfile is in the root directory of your repository.
In my case I had initially kept the Procfile in a subdirectory. Moving it to the root directory solved the problem.
For people who are trying to deploy a django web app, take note that the above step may cause another issue - of heroku unable to reach till the wsgi file residing in the subdirectory.
I solved it by referring to the below thread -
How can I modify Procfile to run Gunicorn process in a non-standard folder on Heroku?

The following worked for me.
As per this Heroku help page:
To fix:
Remove the existing buildpacks with heroku buildpacks:clear.
You will need to add an empty commit and redeploy for the changes to
take effect:
git commit --allow-empty -m "Adjust buildpacks on Heroku"
git push heroku master

You might check your python version. I tried to deploy my Django project so my procfile looks like this web: gunicorn blog.wsgi --log-file - and I also got the same error couldn't find that process type. and I found that Heroku only support python-3.6.4 and python-2.7.14 while I just had python3.5. You can type:
python -V
to see what python version you are using now. if not, you can download python 3.6. I followed this How do I install Python 3.6 using apt-get?
Ubuntu 14.04 and 16.04
If you are using Ubuntu 14.04 or 16.04, you can use Felix Krull's
deadsnakes PPA at
https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa:
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get update
sudo apt-get install python3.6
Alternatively, you can use J Fernyhough's PPA at
https://launchpad.net/~jonathonf/+archive/ubuntu/python-3.6:
sudo add-apt-repository ppa:jonathonf/python-3.6
sudo apt-get update
sudo apt-get install python3.6
and remember to keep you python 3.5. Don't remove it. and specify your python version in the runtime.txt file: python-3.6.4 and run:
heroku ps:scale web=1 --app [my app's name]
and the problem solved. I hope my answer might help you.

In My case the error was solved by just creating space between web and gunicorn
Before:
web:gunicorn --pythonpath app app.wsgi
After:
web: gunicorn --pythonpath app app.wsgi

While it's not Python, in my case, I had heroku/java followed by heroku/pgbouncer. In Heroku's Settings, I switched them so heroku/pgbouncer was on top. This fixed the issue. Perhaps your buildpacks need to be ordered differently if you are using multiple.