pip install --dry-run --report and pip inspect were added so tools can leverage the main pip algorithms without being implemented in pip or using it’s internals. So in a way, yes, we added small, very generic, easy to maintain features so we can avoid some further scope creep.
To give an example, pip list --outdated could easily have been implemented by composing pip inspect and pip install --dry-run --report - --quiet --upgrade.
And @woodrufw has already shown interest in using these new feature so pip-audit does not need the pip internals anymore, so I took that as a sign that we were on the right track.
Yes, it is not easy to draw the line, and the boundary has changed over time and will probably change again in the future.
My (very personal) feeling is that, at this point in time, the pip team is so small, and there is so much to do to just to make the existing pip features consistent with each other, to support new standards and new python versions, to deprecate legacy behaviours, etc… that I tend to cringe at the idea of adding new large features that could live outside, since just the review would divert us.
Now, don’t take me wrong: I fully agree that pip-audit is a very useful and important feature, and making it available in an ubiquitous way is desirable.
But I think that at this point in time, there must be better options than including it in pip.
For instance, to make it ubiquitous, could we imagine to add it to get-pip, or ensurepip ? And/or should pip grow a way to have subcommands as plugins, like git does ?