Feature Request: Constraints for generating first uv.lock when migrating

[mrcljx]

When migrating from Poetry (or other solutions) I want to ensure that the generated uv.lock does not accidentally upgrade any packages.

The docs say:

If resolution output file exists, i.e. a uv lockfile (uv.lock) or a requirements output file (requirements.txt), uv will prefer the dependency versions listed there.

So what I assumed would work is:

1. Transform poetry dependencies (wrote a small script).
2. Export a requirements.txt from poetry.lock via poetry export.
3. Run uv lock

Sadly that didn't work (docs might be confusing here, I guess the latter just works with uv pip). I then assumed that maybe I can do:

uv lock --constraint requirements.txt

But that option does not exist.

What seems to have worked is to generate a fake uv.lock from my script, but I'm also not sure whether that really worked: I get a log statement that the lockfile is ignored because requires-dist doesn't match (I'm not generating that one).

It would be great if I could somehow provide constraints to uv lock. Or am I'm overlooking some existing feature?

[charliermarsh]

I think you could take the output of that requirements.txt, and add it to the pyproject.toml under constraint-dependencies

[project]
name = "foo"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = ["anyio"]

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[tool.uv]
constraint-dependencies = [
    "anyio==3"
]

Then run uv lock. Then remove the constraint-dependencies and run uv lock again, and it should preserve the versions to the extent that it can.

[zanieb]

Feel free to open again if that's not working for you.

[mrcljx]

Worked like a charm. 👍

[charliermarsh]

That's awesome.