Rely on Pipfile.lock instead of requirements.txt

[mccalluc]

• Fix #209
• Remove Pipfile.lock from .dockerignore, since the install in Docker will depend on it. (Ignored files can not be added to the image.)
• Bump base image to python 3.10 to be consistent with Pipfile.lock.
• Remove requirements.txt and references to it in the docs.
• Split COPY . ./ into separate COPY statements, so rebuilds that touch the code but not dependencies will be quicker.

I've built and run this locally, and it works: One possible next step is to do the docker build in CI, and point Cypress at that.

---

I also notice this warning when I run the docker image:

docker build --tag clima .
docker run clima
...
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.

I haven't used gcloud, but it looks like it can work either with a docker image (what clima is doing, I believe), or with python source code. I'm a little out of my depth here, but even though it's running inside a docker container, it is still just running a development server. My guess is that with a WSGI server performance might be a little better, or the google bill might be a little smaller.

If this is worth worrying about, it might be simplest to drop our Dockerfile, and use the gcloud python source code option. One constraint there is that they do not support Pipfile. Another option is pip-tools : essentially keep your high-level dependencies in requirements.in, and compile a requirements.txt that tracks dependencies.

[FedericoTartarini]

@mccalluc thank you again for your great work.

May you open a separate issue about this:

I also notice this warning when I run the docker image: docker build --tag clima . docker run clima WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. I haven't used gcloud, but it looks like it can work either with a docker image (what clima is doing, I believe), or with python source code. I'm a little out of my depth here, but even though it's running inside a docker container, it is still just running a development server. My guess is that with a WSGI server performance might be a little better, or the google bill might be a little smaller. If this is worth worrying about, it might be simplest to drop our Dockerfile, and use the gcloud python source code option. One constraint there is that they do not support Pipfile. Another option is pip-tools : essentially keep your high-level dependencies in requirements.in, and compile a requirements.txt that tracks dependencies.

Yes, currently we are using a docker image and deploying it using cloud run. I only was aware of this solution, I did not know that we could have deployed the code on Google Cloud run in another way. Please let me know if you have the time to look into this in a bit more depth, maybe we can find a better solution to deploy our applications in the future. One major downside of using Docker images is that they are very slow to start if no one has used the application before.