[BUG] [python-fastapi] Improved DockerFile caching with pip install

[jwhtkr]

Bug Report Checklist

• [X] Have you provided a full/minimal spec to reproduce the issue?
• [ ] Have you validated the input using an OpenAPI validator (example)?
• [X] Have you tested with the latest master to confirm the issue still exists?
• [X] Have you searched for related issues/PRs?
• [ ] What's the actual output vs expected output?
• [ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The generated DockerFile re-installs the python dependencies on every change of the underlying code instead of performing that separately from installing the generated library

openapi-generator version

the online test generator (or the master one)

OpenAPI declaration file content or url

The petstore API

Generation Details

Steps to reproduce

• Generate the server stubs with the python-fastapi generator
• run docker compose up --build in the generated code directory (as directed by the generated README.md)
• change/add/remove/etc. a file in the project
• re-run docker compose up --build again
• The command takes a long time as the cached pip install is dependent on the invalidated (changed) source files and re-installs all of the dependencies from scratch again.

Related issues/PRs

A fixing PR could also address the DockerFile bug reported in #11006. (Copy from builder instead of test_runner)

Suggest a fix

Add

COPY ./requirements.txt ./requirements.txt
RUN pip install --no-cache-dir -r ./requirements.txt

right before

COPY . .
RUN pip install --no-cache-dir .

Unfortunately, there is one issue with doing this, which is that in the setup.cfg there are additional dependencies specified via

[options]
install_requires = fastapi[all]

that don't get respected when breaking the install into two steps as suggested. This should also get moved into the requirements.txt.

However, changing the line in requirements.txt specifying the fastapi==... dependency to fastapi[all]==... introduces dependency version issues. Thus, there is some work to re-adjust the pinned versions of the dependencies to be compatible. Note that for myself I adjusted all of the version pinning from a strict == pin to a looser >= and let pip sort things out and have not noticed any issues so far. So doing that could be a workaround until versions get sorted, but YMMV.