I think both can be true: I can absolutely say the same thing for PyPI but I’d never say that should prevent us from adding new features. I can appreciate that a new feature comes with an essentially never ending support burden, but there is a line somewhere that has to be drawn to continue to give users the features they need, and strike a balance between being minimizing support and making a useful tool.
The technical reason is that we want to align with how pip works and it’s functionality, but pip doesn’t have an importable API, which makes developing tools like this really cumbersome. We have to end up doing weird stuff to wrap the CLI, vendor parts of pip into our project, and there’s still a ton of rough edges.
But: I’m not asking for the pip team to fix this, partly because I realize that this would be an even larger support burden than any one subcommand I could propose, and partly because I think even if we all decided to go down that path and do it ‘right’ it would probably be a long time before we had this available to us.
I’m not sure this is an apt comparison: black has nothing to do with pip or packaging. A better comparison would maybe be “why has pipenv and poetry become popular without being pip subcommands” and the answer is because they a) offered features that pip doesn’t have and b) either decided not to become part of pip or were told they couldn’t be.
The single biggest complaint I see by Python packaging users, again and again, is that we have a very fractured ecosystem with lots of differing and competing tools. On one hand: I like this, because it means that we have an ecosystem that’s so able to facilitate new ideas that anyone can go and create their pet project if they want to. On the other hand, it means we (across the ecosystem) have an incredibly complicated and arduous learning curve for new users (and existing users!).
I think a single tool as a panacea is very likely a fallacy but I do see value in offering a single, canonical tool that is widely distributed and offers the most critical features for users to use the ecosystem most effectively. My argument is that knowing if you’re installing something that has a vulnerability or is malicious is, today, one of those features.
To be clear, pip-audit has never used pip internals. We use https://pypi.org/p/pip-api/, which wraps pip’s CLI with an importable API. It comes with a maintenance burden and limits what we can do, but we wanted to respect that pip doesn’t have an importable API itself.
Yes, this is exactly right. We depend on pip’s dependency resolver, as well as related things for requirements file parsing, and reporting on the current environment.
I could imagine this, and would be open to it, but would still want to work on including the subcommand in pip directly as this doesn’t really do anything to resolve the technical challenges of building a separate tool against pip.
The “externally maintained subcommands” idea was kind of what I was trying to approach with the original proposal to vendor pip-audit into pip and mount it as a subcommand.
I hesitate to say a plugin system would be a good way to solve the problem here, since we’re talking about overall maintenance burden and I imagine this would require pip to not only maintain an API for plugins but also the plugin system itself, manage compatibility across pip versions and plugin versions… etc.
I probably should have led with this: I very much don’t want to add any increased work on any existing pip maintainer (aside from what would be unavoidable to land the feature) and my assumption was that regardless of how this is implemented, we’d definitely want to continue to own any maintenance/support around the subcommand.
I have bandwidth, but: I historically haven’t tried to contribute significantly to pip because I tend to pitch in in places where either a) I have a unique ability to help or b) things don’t seem to be going well. My impression of pip’s current state is that neither of those are true (with the exception of a dire need for vulnerability management features, which I’m working on 
). If that’s not the case, you could pretty easily convince me to help out.
That said, I also have the ability to pay for development work. Almost all development on pip-audit was paid work and ongoing maintenance of pip-audit, regardless of where it lands, as well as related work is already in a statement of work with @woodruffw’s team that will continue into 2023. It would be very reasonable for me to include additional pip maintenance in that if we’re working towards a pip audit subcommand.
And: I can also pay maintainers, especially when the work is somewhat related to open source software security, which I could argue all pip development is. I’m assuming the existing maintainers aren’t necessarily in a place where they can turn $$ into “more maintenance” but if that isn’t the case I’d very much like to talk to you: di@python.org