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 iniital 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

Both : and :: syntax are accepted, noted in helptext with double-: as [pyproject-path::]groupname.

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. ↩

[webknjaz]

@reactive-firewall did you generate that with an LLM?

[sirosen]

I was wondering the same thing. It has a clear split between what looks like generated junk at the start and a small human comment at the end.
I really don't want to get dragged off topic in this PR. It isn't the time or place for it. However, this is borderline spam.

@reactive-firewall, FYI we are currently working on an LLM usage policy which includes a requirement of disclosure when these tools are used. Please make sure that your comments are making a meaningful contribution. Remember that they take time and effort to read and respond to, and many projects have extremely limited resources -- a few hours per week from one or two people. Spending even half an hour writing a good reply is a significant chunk of my time budget for open source work.

[sirosen]

Okay, I'm going to wait a day and mark these off-topic.

@reactive-firewall, I know this thread probably doesn't feel great for you, so I want to make sure we part on the best terms possible. One thing I'll note is that the bulleted list, all with emojis, all with the same starting formula, is a bit of a red flag. I also stand by what I said that I don't know that any of those three bullet points add anything. The first recapitulates literally the first line of the PR description, Resolves #2062. I recommend giving some attention to how your initial interaction will be perceived, in the present (broader) context. Cheers! 👍