Integration into pip

[woodruffw]

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)?

[woodruffw]

Another thing: pip will presumably drop support for Python 3.6 shortly after it goes EOL, so we should follow and codify a similar deprecation schedule to ensure we're not difficult to integrate.

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

[woodruffw]

Exploratory tasks: we should independently determine how difficult integration will be, and determine how best to detect when pip-audit has been vendored into pip (as part of enabling/disabling functionality).

[woodruffw]

Here's a brain dump of some of the technical changes/tasks that'll be necessary as part of vendoring pip-audit into pip:

• We'll need to evaluate each of pip-audit's dependencies, bucketing them as follows:

  • Core functionality: these must be vendorable (or already vendored) into pip, which means that they can't be (or depend on) native extensions. They should also meet whatever vendoring criteria pip sets forth.
  • "Feature" functionality: there are some things pip probably won't want, like our SBOM support. We'll want to gate that code appropriately, such that it either isn't vendored at all or is appropriately "fused off" and can't be reached from pip. One possible approach for this is to use extras, e.g. pip-audit[sbom].

• We'll need to figure out how pip will invoke pip-audit. Some options:

  • pip can act as a command builder, re-using the CLI that pip-audit already exposes
  • We could figure out some way to mash pip-audit's argparse.ArgumentParser into pip's as a subcommand
  • pip could use the pip-audit APIs, which would need to be formally stabilized and made more public

• We'll need to figure out the pip and pip-api interaction. Does it make sense for pip-audit to check whether it's running under pip and use pip's internal APIs instead, or does it make sense for pip to vendor pip-audit?

There's probably other things I've missed. CC @tetsuo-cpp, since you might remember some other bits 🙂

[di]

I turned this issue into a roadmap here: #335