marimba install overwrites dependencies when using requirements.txt

[GermanHydrogen]

The marimba install command seems to overwrite dependencies when it installs from a requirements.txt. This means a lower version of a dependency of marimba could be installed by the command, which then could break the following pipeline steps.

I noticed this with ifdo-py, which is a sub-dependency of a pipeline. The dependency marimba-rails depends on ifdo-py and specified the version as ">=1.2.5".
When testing the dev-branch version of marimba, marimba-install then installed version 1.2.5 instead of keeping version 1.3.0, which would be compatible with both marimba and the pipeline.

[cjackett]

Thanks for reporting this. A couple of observations that may be relevant.

Looking at the git history, this issue was filed on June 11, 2025, five days after we migrated the pipeline installer from pip to uv (June 6, 2025). It is likely that the downgrade you observed was caused by uv's dependency resolution behaviour at that version, rather than the previous pip-based installer (pip does not downgrade already-installed packages by default).

We have added a defensive fix in 6314211: the installer now freezes the current environment with uv pip freeze before each install and passes the filtered output as a constraints file (-c). This means any package already installed at a compatible version cannot be resolved to a lower one, regardless of what the pipeline's requirements.txt specifies. Editable and local installs are stripped from the freeze output before writing the constraints file, as uv rejects unnamed references in constraints files.

That said, we were unable to reproduce the downgrade with current uv using a plain uv pip install -r requirements.txt. Current uv appears to leave already-installed packages at their existing version by default. It is possible the behaviour was fixed in a uv update between June 2025 and now.

Could you confirm whether you are still able to reproduce this issue? The defensive fix in 6314211 is currently on the dev branch. If you cannot reproduce it on current Marimba, it's possible the issue was resolved by a uv update in the interim and our change is simply a defensive measure to ensure it cannot recur.