feat: add write_uv_constraints command to manage uv constraint-dependencies

[feanil]

Summary

Adds a new edx_lint write_uv_constraints command to support repos migrating from pip-compile to uv.

The problem: uv lock has no --constraint CLI flag — version constraints must live in [tool.uv].constraint-dependencies inside pyproject.toml. Without tooling, every repo would need to copy-paste edx-lint's global constraints and keep them in sync manually.

The solution: A command that:

• Reads the bundled global constraints from edx_lint/files/common_constraints.txt
• Optionally merges in repo-specific constraints from a local file (typically constraints.txt next to pyproject.toml)
• Writes the merged list into [tool.uv].constraint-dependencies, preserving all other pyproject.toml formatting and content via tomlkit
• Adds a prominent "DO NOT EDIT" comment above the key on first write
• Is idempotent: running it twice produces the same result

Usage:

# Global constraints only
edx_lint write_uv_constraints

# Merge with repo-specific constraints
edx_lint write_uv_constraints pyproject.toml --local constraints.txt

The constraint-dependencies list is fully machine-managed. Humans should never edit it directly — global changes go in edx_lint/files/common_constraints.txt, repo-specific pins go in a local constraints.txt.

Changes

• edx_lint/cmd/write_uv_constraints.py — new command module
• edx_lint/cmd/main.py — register command in dispatcher and help output
• requirements/base.in — add tomlkit as a direct dependency (was already present as a transitive dep of pylint)
• test/test_cmd.py — 10 new tests covering all key behaviours
• requirements/*.txt — regenerated via make upgrade

[feanil]

openedx/openedx-aspects#359 shows what the implementation of this would look like.

[bmtcril]

Thanks for taking this on, it was definitely the worst missing piece of the initial uv stab. I just have the one non-blocking concern that we probably can't do anything about.

[bmtcril]

I do have some concerns about this, since it would be a divergence from what we expect to happen? I think that the overall direction is to move away from these files eventually anyway, right?

[feanil]

Yea, in an ideal world, we could reference global and local constraints directly in the pyproject.toml. Another alternative that I was considering is instead of adding a file here. We could add a new tool directive section to pyproject.toml for edx_lint so that we could add local constraints there instead and it would combine the local list with the global list. I opted for the constraints.txt file because it's where people would look to add this but thinking through it again, the tool directive might be a better option, the comment in the pyproject.toml points to the edx-lint section in the same file and because it's not a constraints.txt file, but a new directive, people will be less surprised by it having different capabilities.

What do you think of this alternative approach? Worth pursing? If so I can update the PRs to do that instead before we land it.

[bmtcril]

Ooh, I think I like that better. If we're biting the bullet on this fairly major update that seems like the more future-proof solution