Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

luisgcoding
Copy link

@luisgcoding luisgcoding commented Oct 14, 2025

This PR adds support for RFC 9457 (Problem Details for HTTP APIs), enabling pip to parse and display structured error responses from package indexes that implement this standard.

What Changed

  • Added ProblemDetails data class to parse RFC 9457 responses
  • Created HTTPProblemDetailsError exception for structured HTTP errors
  • Modified raise_for_status() to detect and handle Problem Details responses
  • Falls back to existing error handling for non-RFC 9457 responses

Implementation Details

When pip receives an HTTP error response with Content-Type: application/problem+json, it:

  1. Parses the response as RFC 9457 Problem Details
  2. Raises HTTPProblemDetailsError with structured error information
  3. Displays human-readable error messages with status, title, and detail fields

Non-RFC 9457 responses continue to use the existing NetworkConnectionError behavior.

Based on this discussion in the forum, this implementation could potentially lead to a PEP proposal. This PR is intended to start the conversation with the pip maintainers about adopting RFC 9457 support in the packaging ecosystem.

@luisgcoding
Copy link
Author

pre-commit.ci autofix

@luisgcoding
Copy link
Author

pre-commit.ci autofix

@luisgcoding luisgcoding marked this pull request as ready for review October 15, 2025 14:50
@ichard26
Copy link
Member

Hello! Thanks again for following up! I regret to inform you that we currently have limited capacity to review contributions, so it may take some time until we are able to review your PR. We would appreciate your patience.

I take it as there are no publicly available indices that provide RFC 9457 error responses?

@notatallshaw
Copy link
Member

Also, it wasn't clear to me from the DPO discussion that is ready for implementation, should this not be a packaging PEP first and gain community consensuses? @pfmoore

@pfmoore
Copy link
Member

pfmoore commented Oct 15, 2025

I agree, I think we should probably wait until this is a standard before implementing it here. Or at least until PyPI implements it (there's a possibility that PyPI won't wait for a standard, and if something is available in PyPI there's a decent justification for us implementing it anyway - but that would be on a case by case basis).

@notatallshaw notatallshaw marked this pull request as draft October 15, 2025 18:17
@notatallshaw
Copy link
Member

@luisgcoding thanks for the PR but I'm marking it as draft for now. I guess either:

  • PyPI updates it's current non-standard message to said RFC standard (but not Python packaging standard), and we update update pip's logic to reflect that
  • Or, a Python packaging PEP is created and accepted and we can implement that

@luisgcoding
Copy link
Author

luisgcoding commented Oct 15, 2025

Hello! Thanks again for following up! I regret to inform you that we currently have limited capacity to review contributions, so it may take some time until we are able to review your PR. We would appreciate your patience.

I take it as there are no publicly available indices that provide RFC 9457 error responses?

Thank you for the information @ichard26 . You are right as far as I know there are no public registries that support RFC9457 responses yet.

@luisgcoding
Copy link
Author

@luisgcoding thanks for the PR but I'm marking it as draft for now. I guess either:

  • PyPI updates it's current non-standard message to said RFC standard (but not Python packaging standard), and we update update pip's logic to reflect that
  • Or, a Python packaging PEP is created and accepted and we can implement that

Thanks for the feedback @notatallshaw I understand the concern about implementing this before there's concrete adoption.

A few questions to help me determine the best path forward:

  1. Would it be appropriate to propose this to the PyPI maintainers first? If so, what's the best channel for that discussion?
  2. Do you know what is the best way to start the conversation about creating a PEP for this?
  3. Are there any other considerations I should be aware of when deciding between these approaches?

Happy to keep this as a draft and coordinate with the appropriate stakeholders before moving forward.

@pfmoore
Copy link
Member

pfmoore commented Oct 15, 2025

I would strongly suggest working towards a standard. Even if PyPI implement this without a standard, I'd be cautious about implementing it in pip (my comment above wasn't intended to endorse the idea of us implementing this without a standard, just to note that it was possible).

There's already a discussion on discuss.python.org, so the process to start working towards a PEP is to continue the discussion there, and offer to write a PEP 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.