Integration into `pip`

In the medium-to-long-term, it would be great to make pip-audit a subcommand of pip, i.e. pip audit.

This will involve coordination with pip as the upstream, and requires us to figure a few things out, including but not limited to:

1. If we merge into pip, should we drop our pip-api dependency and use pips internal APIs directly?
2. Does it make sense to maintain a parallel “standalone” pip-audit that has functionality pip might not want (e.g. container scanning)?

[di]

I turned this issue into a roadmap here: https://github.com/trailofbits/pip-audit/issues/335

[di]

If we merge into pip, should we drop our pip-api dependency and use pips internal APIs directly?

I haven’t fully thought this through, but my original plan for pip-audit was that if it was vendored into pip, that it would somehow determine that it was vendored and use pip’s internal API instead of calling out to subprocesses – effectively becoming a wrapper around these internal APIs, allowing any project that uses pip-api to eventually become easy to integrate into pip itself.

That would allow us to vender both pip-audit and pip-api directly into pip, without having to do significant rewrites of either during the vendoring process, and without having to use subprocesses in pip-api.

That said, this hasn’t really been explored yet. While I’ve tried to keep pip-api’s API as close as possible to what pip’s internal APIs, they might have diverged in a way that would make this challenging.

Does it make sense to maintain a parallel “standalone” pip-audit that has functionality pip might not want (e.g. container scanning)?

I think long-term we want to maintain a standalone regardless, with the goal of that standalone being vendored into pip.

We can wait to make a call on what features are included in this until we see how much of a lift it would be to include things like container scanning as part of pip. We could potentially include it as an extra for pip-api, that’s not included when it’s vendored, for example.