fix: skip pip invocation when resolved groups are empty

[henryiii]

See #45, item 2.

🤖 AI text below 🤖

If the requested dependency groups resolve to zero requirements (e.g. empty = []), the pip wrapper ran pip install with no arguments, which crashed with a CalledProcessError traceback. Now main() prints "Nothing to install" and returns normally instead of invoking pip. Includes a regression test that mocks _invoke_pip.

---

📚 Documentation preview 📚: https://dependency-groups--47.org.readthedocs.build/en/47/

[sirosen]

Before we merge, let's add a bugfix note to the changelog?

(I'd be open to setting up scriv or towncrier... But for now, we have an "Unreleased" section.)

[henryiii]

I really dislike those, I dislike having to contribute when those are present, and now one of my projects, pypa/build, has it and it's been terrible IMO. I've developed a system in pybind11 that works pretty well based on PR descriptions, though these days asking an AI to make the changelog at the end works incredibly well. (Even in packaging, for example, with 100+ changes)

[henryiii]

(And yes, happy to update the changelog per PR too, that's better than a system for smaller projects, and rebasing PRs is trivial now)

[sirosen]

By the sound of it, I've had better experiences with those tools, but it probably doesn't matter: my fundamental approach to such topics is to be adaptable to the needs of my projects and peers. I don't need us to change this project at all. 😄

Just to share, at $DAYJOB I've found that scriv has saved us a lot of pain because of how it de-conflicts PRs. We don't waste time rebasing: even if trivial to do, it's extra time cost per PR, and we end up waiting for CI to clear.

[sirosen]

I forgot one thing I wanted to note about changelogs.

these days asking an AI to make the changelog at the end works incredibly well. (Even in packaging, for example, with 100+ changes)

I strongly disagree with this approach. I think the changelog should be written when the change is written, and it should be written with the same kind of deliberate care that is applied to source code.

Not asking you to agree, but I want to make sure to say that aloud so you aren't surprised if I push back on doing something like this here or in another project in the future.

[henryiii]

You should see the pybind11 mechanism. It doesn't require most PRs to be updated after creating it to add the entry with the PR number, it's trivially editable at any time by maintainers without touching CI, and doesn't have a magic final step to combine the snippets that never works correctly.

[henryiii]

I think the changelog should be written when the change is written

It basically is; AI is summarizing commit messages (one reason I use conventional commits, though that predated AI - it's the same thing I used to do by hand based on titles from GH release notes generator) or PR descriptions. For a smallish or simpler project, I'd much rather polish myself afterwards; I use AI to generate the initial changeset, then polish manually. I find that much easier to tell a coherent story than any per-author entry.

If the project is large enough, then that's not as true (that final polish step by someone who knows the whole library is important!), but we are talking about this project. :)

and it should be written with the same kind of deliberate care that is applied to source code.

But they aren't. The quality and style of the snippets vary widely. AI is much more consistent, and you can polish better when you see all the changes side by side.

Again, the project can't be huge.

See https://packaging.pypa.io/en/stable/changelog.html - 26.3 was heavily AI assisted, and 26.0 was manual. The type of PR did change a bit (a lot more little fixes in 26.3 from AI contributors), but I think the quality is pretty similar. Also see pypa/cibuildwheel and see if you can guess which ones used https://github.com/pypa/cibuildwheel/blob/main/.agents/skills/changelog-entry/SKILL.md to seed the initial changelog, and which ones didn't. Hopefully, you can't. :)

Also, I didn't even know it until a couple of days ago, but at least the last two pybind11 releases used AI instead of the in-repo tooling (though I didn't run it, so I don't know if it found and ran the tooling to help it). 3.1.0 I'm releasing so it will be from the tooling again.

[sirosen]

I don't want to force us to have our whole discussion on this only here, but we are talking! It's worth getting minimally in sync. 🙂

I find that much easier to tell a coherent story than any per-author entry.

100% agree. Changelog fragments do not replace a final edit pass at the time of release.

Some advocates of changelog fragments and conventional commits suggest that it replaces changelog authorship, which is not true. For most projects, it supplements, but does not replace.

If the project is large enough, then that's not as true (that final polish step by someone who knows the whole library is important!), but we are talking about this project. :)

In the context of this project I suggest no change! It's so small and, relatively speaking, low stakes, we should keep it low friction. 👍

(I've had good enough experiences with scriv, in particular, that I consider that also low friction, as an option.)

and it should be written with the same kind of deliberate care that is applied to source code.

But they aren't. The quality and style of the snippets vary widely. AI is much more consistent, and you can polish better when you see all the changes side by side.

I can't pretend away the variance in quality and style. We reach different conclusions about how to handle that reality.

We are divided in some of our opinions. With few exceptions, I've not been satisfied with machine generated prose and documentation. I also find the practice of writing change fragments helpful, if approached as a useful exercise rather than a chore.
Luckily, not only are our disagreements mostly not pertinent to this repo, but we also agree on the value of a changelog in the first place!

[henryiii]

I love changelogs, they are one of my favorite things to read (and you might notice summarizing changelogs is probably the most common article type on iscinumpy.dev!).

I've had good enough experiences with scriv

I've not really had any experience with it, but towncrier I haven't liked. It's tied into the release system in pypa/build, which gives no chance to see it before it's released. We've had it mess up pretty much every possible way, and have had to fiddle with it every release.

I don't like writing little files with no context and magic names. It's not terrible, but pybind11's system runs circles around it for me. :) I would tell you to try nox -s make_changelog, but we've just collected the fragments and cleared the needs-changelog tags, so it actually comes up empty right now. I really like that I can iterate and change the PR text or title (which controls the category) and rerun the collection until I'm happy with it.

(Of course, you could argue that we could move towncrier to a manual step, but I'm not fond of manual steps only some people know how to do, but pybind11's a manual step too, so I'm being completely biased because I wrote it, which is probably true).

Note

I use all sorts of changelog systems, so willing to try about anything. Only referring to preferences here. :) Using AI to start the changelog has been second only to pybind11's system. It basically replaces me manually building from scratch based on GH's PR-based changelog and .github/release.yml, which I often set. Which has an API, by the way, something like this:

gh api repos/{owner}/{repo}/releases/generate-notes \
-f tag_name=v1.0.0 \
-f target_commitish=main \
--jq .body

I've not been satisfied with machine generated prose and documentation.

I don't like AI output either, especially when it's passed off as human (hence the AI tags I require of myself, and AI disclaimers I put on my posts). But summarizing is better than expanding, and in general it is picking up what users wrote -- in fact, if you put the pybind11 "Suggested changelog entry" PR heading into a PR, I think it will actually notice that and copy it verbatim most of the time. I also like GLM here, it produces better, shorter text than Claude or other closed source models. I've gone on record saying it's the only model that produces output I only dislike instead of hate. :) I think 5.2 is a bit more Claude-like, but still okay. 5.1 was great. That's what I've used for cibuildwheel and some others; it needs less editing than Claude. Unfortunately, due to RLVR scaling better than RLHF in training, that's likely a trend that will continue everywhere.

If you want to use scriv or any other system here, I'm not stopping you, just telling you my preferences. :)