Repository navigation
Bundle images resolve ranged dependencies past uv.lock #377
Description
Problem
Server images install each bundle's dependencies outside the lock. The image builders in packages/sie_server/Dockerfile.cpu, Dockerfile.cuda12, and Dockerfile.cuda13 do two steps:
python -m sie_server.cli resolve-deps --bundle <bundle>writes the bundle's dependency specifiers to a requirements file.pip install --target=/app/bundle-libs -rthat file installs them.
/app/bundle-libs is then put ahead of the shared virtualenv on sys.path. Bundle YAMLs mostly use ranges, so pip resolves each one to the newest matching release at build time. That release then shadows the version pinned in uv.lock, which is the one CI tests against.
For example, the default bundle declares gliner>=0.2.26,<1, and uv.lock pins gliner 0.2.26. PyPI now has 0.2.27, 0.2.28, and 0.2.29, so a default image built today serves gliner 0.2.29, a version no test ran against. The same applies to every ranged bundle dependency, such as gliclass, gliner2, glirel, and docling.
Consequences:
- Two builds of the same commit can ship different dependency versions.
- A dependency release can change serving behaviour without any change in this repository.
- Code that checks a dependency it patches or wraps, as some adapters do, can pass CI and fail in the image.
Proposal
Make bundle installs reproducible from the repository:
- Constrain bundle installs to the lock. Export the locked versions (for example
uv export --frozen --no-hashes) and pass them to the bundle install as a constraints file (pip install -c). Any package the lock already resolves then keeps its locked version. Only packages absent from the lock float. - Or lock each bundle. Have
resolve-depsemit exact versions from a per-bundle lock, checked in and refreshed likeuv.lock. - Record what shipped. Write the resolved
pip freezeof/app/bundle-libsinto the image, so any deployed version can be checked.
Acceptance
- Building the same commit twice installs the same versions in
/app/bundle-libs. - Every package that
uv.lockpins is installed at its locked version in each bundle image, unless the bundle deliberately overrides it (for example the transformers 5 bundle), and that override is written down. - CI fails if a bundle image resolves a locked package to a different version without such an override.
Activity
fix(server): pin transitive bundle deps and tolerate a split lock
fix(server): stop bundle constraints from pinning the wrong torch edges
test(server): skip bundle resolution unless opted in
fix(server): type the lock edge fields and check each image install
fix(server): leave a contested lock neighbor unpinned
fix(server): constrain bundle image installs to uv.lock (#653)
build(bundles): lock and verify complete runtime overlays (#802)
svonava commentedon Oct 19, 2026
Fixed by #653 and #802.
Bundle images now install a saved dependency closure rather than resolving ranges during the build. The 15 checked-in target locks cover all 11 released Linux amd64 images and the four supported CPU arm64 combinations. Packages retain root-lock pins unless an explicit, documented bundle exception applies. Required CI rejects stale or inconsistent locks, and image builds verify and retain the installed
/app/bundle-libsinventory.Validation includes 273 focused controls, all 15 saved-lock reads, and current-head CI/container builds. The repeat-install experiment used two fresh CPU CT2 component containers, which produced identical complete four-package overlay inventories; it did not rebuild all 11 images twice.
This closes the dependency-version drift and installed-inventory acceptance criteria. It does not claim whole-image byte reproducibility or GPU runtime qualification.