Backend build process is slow

[chetanr25]

Describe the Bug

Two related issues with our Docker-based dev workflow:

1. make up doesn't run the latest backend - it just starts the already-built container. If requirements.txt has changed (e.g., a new package was added), the running container still uses the stale image with old dependencies. You have to manually remember to run make build first, which is easy to forget and leads to confusing runtime errors.

2. make fireform is significantly slow when requirements.txt changes every time a dependency is added or removed, the entire pip install layer in the Dockerfile is invalidated and all packages are re-downloaded and re-installed from scratch. This takes a long time and isn't generally expected for adding a single package.

Steps to Reproduce

Issue 1: make up ignores new packages

1. Add a new package to requirements.txt
2. Run make up
3. Try to import the new package in the app fails with ModuleNotFoundError
4. Only works after manually running make build then make up

Issue 2: Slow rebuilds

1. Run make fireform to get a working setup
2. Add one small package to requirements.txt
3. Run make fireform again
4. Observe that pip install re-installs all packages from scratch, not just the new one
5. This is especially painful when switching branches to test other PRs or your own work each branch may have slightly different dependencies and every switch triggers a full reinstall

Expected Behavior

• make up should always run the latest version of the backend, including any newly added packages.
• Rebuilds after a small change to requirements.txt should be fast (seconds, not minutes). Adding one package shouldn't force reinstallation of all existing packages.

Impact

This significantly slows down the development loop, especially for:

• Reviewing and testing other contributors' PRs that add new dependencies
• Switching between your own feature branches
• Onboarding new contributors who hit stale-container issues

Optimising this would improve the team's productivity across the board.

Possible Fix

We should revisit how the Docker image is built and how make up interacts with it. Some ideas:

• Add a caching strategy for pip installs in the Dockerfile (e.g., BuildKit cache mounts)
• Consider faster package installers that handle cached/incremental installs better
• Make make up aware of dependency changes so it rebuilds when needed
• Possibly sync dependencies at container startup so new packages are picked up without a full image rebuild

[marcvergees]

I agree this is a very important issue we need to address in a close future. Definitely it happens the same to me, every single time I'm reviewing any of your changes I need to rebuild the whole image, which tends to take 5-10 minutes. Thoughts @vharkins1?

[chetanr25]

I looked into this a bit and I think we can solve this in two ways.

1. Better caching strategy in the Dockerfile

Docker BuildKit supports cache mounts that persist across builds. Instead of re-downloading everything on each layer invalidation, we can mount a persistent cache directory for the package installer. This is already a common pattern in production Dockerfiles but we aren't using it currently.

2. Replace pip with uv for package installation

I came across something cool called uv while researching ways to optimise this. It's a drop-in replacement for pip written in Rust by the same team behind ruff (which we already use for linting). From what I've read, it's 10-100x faster than pip for dependency resolution and installation. Correct me if I'm wrong, but I think this could be a huge win for our Docker builds.

The nice part is uv can work as a straight pip replacement uv pip install -r requirements.txt so we don't need to migrate to pyproject.toml or change our dependency management workflow at all.

Some references:

• uv: Python packaging in Rust - Astral's announcement blog post
• uv GitHub repo - docs, benchmarks, usage
• Using uv in Docker - official guide for Docker integration
• Docker BuildKit cache mounts - Docker docs on --mount=type=cache
• uv pip interface docs - drop-in pip replacement usage

Combining both (uv + BuildKit cache mounts) should make rebuilds near-instant even when requirements.txt changes. Would love to hear thoughts on this before I put up a PR.