Report install errors and failures in JSON format

[atugushev]

What's the problem this feature will solve?

Currently, pip install --report reports errors and exceptions in plain text which is inconvenient for parsing.

Describe the solution you'd like

Instead of

$ pip install pip-tools==6.8.0 pip==20.1 --dry-run --report -
ERROR: Cannot install pip-tools==6.8.0 and pip==20.1 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested pip==20.1
    pip-tools 6.8.0 depends on pip>=21.2

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

report errors and exceptions in JSON format, for example:

$ pip install pip-tools==6.8.0 pip==20.1 --dry-run --report -
{
  "error": {
    "code": "resolution_impossible",
    "description": "Cannot install pip-tools==6.8.0 and pip==20.1 because these package versions have conflicting dependencies",
    "extra": {
      "requirements": ["pip"]
    }
  }
}

Alternative Solutions

Let users parse plain text and let them hope for the best.

Additional context

jazzband/pip-tools#1654 (comment)

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[jeffwidman]

👋 Hi from the team.

We'd love to see something like this, it'd make our error parsing code a bit less fragile.

This is actually a common problem we encounter across package managers in many language ecosystems, so if you are looking for design input, feel free to give us a holler (our main issue tracker is https://github.com/dependabot/dependabot-core/) and we'd happily share some of what we've observed elsewhere.

Also, what's the next step on this issue?
Is it:

1. Maintainers need to make a decision on whether to accept this
2. Maintainers are 👍 to this, so needs someone to flesh out the API design and then implement it
3. Maintainers prefer want a full-blown PEP on this.

[pfmoore]

IMO, this is a reasonable suggestion, so I think it's awaiting someone to take it further. This isn't something that needs a PEP, as it's a pip implementation matter, but it will have an impact on how our error handling code works, so I think it might be worth some sort of discussion about how this will be implemented before someone launches into writing a PR. (That's assuming an external contributor wants to tackle this, rather than waiting for one of the pip maintainers to have the time to pick it up).

[pradyunsg]

+1 to all that Paul said. To be explicit, the next step is 2 with the caveat that we should discuss the design here before implementing it, since it redoes a fairly foundational design piece of the code base's CLI.

FWIW, this request also aligns nicely with the UX design direction that #10421 sent us down (where all errors follow the same schema/structure, and have unique user-facing error codes). I wouldn't be opposed to migrating just those errors to be JSON-serializable for the output and then leaving out the long tail of errors that need to migrate to the DiagnosticError model.

And, https://github.com/pradyunsg/diagnostic became a thing last week. So, breaking this up into smaller design problems is also doable. :)

[chrysle]

On behalf of pip-tools, I'd be willing to pick this up.

[ichard26]

It's been a little bit so I'll speak for the project (with my triager hat on).

We generally would welcome a feature like this. However, as @pradyunsg brought up, this is going to require a nontrivial amount of work to come up with a design and port the codebase's error handling to support this new feature. For some initial guidance, pip's errors are split into two groups:

• The modern errors which have a pretty presentation and standardized set of basic metadata (including an unique error code). These errors derive from DiagnosticPipError in pip._internal.exceptions. For more details, see Add additional diagnostics to our error messages #10421 (comment).
• All of the other errors. These are simply subclasses of Exception (through various immediate parent subclasses)

There's actually one more: unhandled exceptions that bubble up resulting in crashes, but those should be easy to tack on to whatever infrastructure we end up with as a special case.

Errors (barring the last category) are eventually caught and presented in pip._internal.cli.base_command.

Alternatively, you can just design something that works for the relevant errors that pipx would need at the minimum. Either way, you'll have to special case for the ResolutionImpossible error at least (or provide a way for additional structured information to be tracked).

Feel free to explore the codebase and start drafting a proposal @chrysle.

[chrysle]

Thanks for the informative response! I'll see what can be done.