Implement a --group flag for dependency-group parsing for pip-compile

[sirosen]

Resolves #2062 ¹

This is an initial proposed implementation, but even after finishing it, I have two major outstanding questions.

Q1: Should --group be considered a source file?

I didn't merge parsed --group inputs into src_files, but I did count len(src_files) + len(groups) in a couple of contexts to make it behave similarly.
I'm not sure if this was the right approach, or if I missed or misunderstood the goals of the src_files checking in any way.

Extra attention in this area during review would be appreciated -- as a new contributor, I did my best to follow the existing code and keep the changes small, but may have made mistakes.

Q2: What tests are missing?

The initial tests are pretty simple and limited. Probably, more tests would be worthwhile, but it's hard to tell what cases would be useful vs redundant with existing tests.
What additional checks seem important?

Note: Accepts pyproject.toml:X and pyproject.toml::X

Update: This was removed from the PR!

Although supporting :: and : side-by-side is easy from the perspective of maintenance and support, after plenty of time to think about this, I decided that it provides a worse experience for users. It's different from pip install --group and doesn't have a strong enough justification for that difference.

I decided on this after weighing the options from #2062 and would be willing to adjust if there's a strong objection, but think this is the best approach.
pip-compile can have its own syntax, but accepting the pip install syntax is an easy gain for compatibility.

Because the filename part is already optional, the behavior which handles output of options also naturally handles the : vs :: variation.

Commits

• Add --group to pip-compile options
• Implement dependency-groups parsing, based on pip
• Preserve input arg for --group when writing output
• Add tests for [dependency-groups]

Checklists

Contributor checklist

• Included tests for the changes.
• PR title is short, clear, and ready to be included in the user-facing changelog.

Maintainer checklist

• Verified one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

Footnotes

1. Aside: sorry it took so long to submit a PR! This has been on my to-do list for a while. ↩

[sirosen]

I've rebased, added some missing tests, and added a changelog entry.

After the rebase, I also moved some things into piptools._internal (which is new since this opened!).

I also removed support for pyproject.toml::groupname -- only a single colon is now supported. I think it's better, in this case, to be consistent with pip and uv and not introduce something new. If we use two different syntaxes, we'll be stuck with both forever. (Which is fine, but IMO not the best user interface.)

I'm going to re-evaluate the treatment of src_files which I was unsure about at the time of the original PR.

[sirosen]

Okay. I've read back over the src_files codepaths and I think keeping them separate is the right call for now.

I would like to do some exploration of possible refactors to that part of the codebase. I think it's possible to define some kind of input object which is built from src_files, groups, output_file, and maybe some of the other flags (--extras? --build-deps-for?) and abstracts away a lot of the combinations and usages which are checked.

---

That more or less concludes my self-review. I think this is ready.

I note that codecov has dropped -- I'm not sure if that's a direct consequence of this PR. I think I might have accidentally allowed it to drop in main. Update: a small additional test seems to have made codecov happy!