Add support for -c constraints in uv add

[charliermarsh]

Summary

Closes #11986.

[charliermarsh]

I didn't want to add a constraints argument to do_safe_lock when only one caller needed it, so I migrated this to a struct with a builder pattern.

[zanieb]

We should probably note these won't be added to the pyproject.toml and explain what final effect they have here?

[zanieb]

We might need to propagate --marker to the constraints, wdyt? I think it's needed for importing a platform-specific lock (e.g., requirements-win.txt)

[charliermarsh]

Can you explain the command that would be run and why we need to propagate?

[zanieb]

pip-compile does not add markers to its single platform output. So pip-compile on Windows will produce a Windows specific lockfile without markers.

To import this, we need to gate the lock to win32, e.g.:

uv add -r requirements-win.in -c requirements-win.txt --marker "sys_platform == 'win32'"

I think in reality, this is actually more complicated :/ because you probably have a single requirements.in and multiple lockfiles. What you really need is:

uv add -r requirements.in \
    -c "requirements-win.txt; sys_platform == 'win32'" \
    -c "requirements-linux.txt; sys_platform == 'linux'"

--marker doesn't work since it's applied to the input requirements.

For a concrete example, here's what I have in my pip migration draft...

For example, take a simple dependency:

tqdm

On Linux, this compiles to:

tqdm==4.67.1
    # via -r requirements.in

While on Windows, this compiles to:

colorama==0.4.6
    # via tqdm
tqdm==4.67.1
    # via -r requirements.in

[zanieb]

I'm not sure if separating input requirements is common. I don't think we should focus on support for that.

[charliermarsh]

Hmm ok... We can add the marker... It should be harmless...

[zanieb]

(Followed-up synchronously because I'm not sure what's best here)

I think not respecting --marker to start is fine. I'm not sure what to do for that use-case yet.