Monolith project requires api, worker, and shared to live in one repo (monorepo) and be able to deploy from one image with 2 entrypoints (one for worker, one for api). The docker script will be bootstrapped to start either relevant service on command.
The monorepo will use Git submodules (see POC repo). In it, we need worker and api to use the same version of shared. Our current tool pip-compile that generates lockfiles with dependency versions does not let us pin the shared version to be same in local development and prod.
Other tools like poetry may allow this functionality. In order to use it in the monolith, it must first be implemented within api, worker, and shared (then later the config can get merged).
This task includes:
- Evaluate alternatives to
poetry (uv? setup-tools?)
- Identify any new prereq work (e.g., to get poetry shared, need to first upgrade all libraries to version X of library Z)
- Cutover to the new tool in
shared, then api, then worker (shared first to ensure compatibility)
Monolith project requires
api,worker, andsharedto live in one repo (monorepo) and be able to deploy from one image with 2 entrypoints (one for worker, one for api). The docker script will be bootstrapped to start either relevant service on command.The monorepo will use Git submodules (see POC repo). In it, we need
workerandapito use the same version ofshared. Our current toolpip-compilethat generates lockfiles with dependency versions does not let us pin thesharedversion to be same in local development and prod.Other tools like
poetrymay allow this functionality. In order to use it in the monolith, it must first be implemented withinapi,worker, andshared(then later the config can get merged).This task includes:
poetry(uv? setup-tools?)shared, thenapi, thenworker(sharedfirst to ensure compatibility)