feat(resolver): enforce PyPI quarantine check for all resolver types

[pavank63]

The PEP 792 quarantine check previously only ran inside get_project_from_pypi(), which is only called by PyPIProvider. Packages resolved via GitHubTagProvider, GitLabTagProvider, or PyPIProvider with a custom index URL bypassed the check entirely.

Add a standalone check_pypi_quarantine_status() function that queries pypi.org for quarantine status and call it unconditionally from both resolve() and resolve_source() entry points. Remove the quarantine check from get_project_from_pypi() to avoid split responsibility.

Closes: #1101

• PR follows CONTRIBUTING.md guidelines

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes extract PyPI quarantine status checking (PEP 792) into a standalone check_pypi_quarantine_status() function that queries the PyPI JSON API and raises ValueError if a project is quarantined. This function is now called unconditionally from both resolve() and resolve_source() entry points, ensuring quarantine validation occurs regardless of which resolver provider is used (PyPI, GitHub, GitLab, etc.). The original quarantine check is removed from get_project_from_pypi(), leaving only logging for non-fatal fetch errors.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: adding a standalone quarantine check function that runs for all resolver types, moving it from PyPIProvider-only scope.
Linked Issues check	✅ Passed	The PR implements Option A from issue #1101: adds check_pypi_quarantine_status() function, calls it unconditionally from resolve() and resolve_source() entry points, and removes the check from get_project_from_pypi().
Out of Scope Changes check	✅ Passed	All changes are directly in scope: new quarantine check function, integration into both resolve entry points, removal from get_project_from_pypi(), and comprehensive unit tests with fixtures.
Description check	✅ Passed	The pull request description clearly explains the problem (quarantine check bypassed for non-PyPI providers), the solution (standalone check_pypi_quarantine_status function called unconditionally), and references the closed issue #1101.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

src/fromager/resolver.py (1)

377-397: 💤 Low value

QUARANTINED falls through to catch-all, logging misleading "unknown status" warning.

If get_project_from_pypi queries PyPI directly (not via entry points) or if a custom index mirrors PyPI's quarantine status, QUARANTINED hits case _: and logs as "unknown status." Add explicit handling:

♻️ Suggested fix

         case pypi_simple.ProjectStatus.DEPRECATED | pypi_simple.ProjectStatus.ARCHIVED:
             logger.warning(
                 "project %r is no longer active: %r: %s",
                 project,
                 package.status,
                 package.status_reason,
             )
+        case pypi_simple.ProjectStatus.QUARANTINED:
+            # Quarantine is enforced at resolution entry points (resolve/resolve_source).
+            # If we reach here, the check either passed or was bypassed.
+            logger.debug(
+                "project %r has quarantine status in index response (checked at entry point)",
+                project,
+            )
         case _:
             logger.warning(

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/fromager/resolver.py` around lines 377 - 397, The match on package.status
in get_project_from_pypi currently falls through QUARANTINED to the catch-all
and logs "unknown status"; add an explicit case for
pypi_simple.ProjectStatus.QUARANTINED in the match block (near the existing
cases for ACTIVE, DEPRECATED, ARCHIVED) and log a clear warning (e.g., "project
%r is quarantined: %s") using project and package.status_reason so quarantined
packages are not misreported as unknown; keep check_pypi_quarantine_status
semantics unchanged at the resolution entry points.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/fromager/resolver.py`:
- Around line 377-397: The match on package.status in get_project_from_pypi
currently falls through QUARANTINED to the catch-all and logs "unknown status";
add an explicit case for pypi_simple.ProjectStatus.QUARANTINED in the match
block (near the existing cases for ACTIVE, DEPRECATED, ARCHIVED) and log a clear
warning (e.g., "project %r is quarantined: %s") using project and
package.status_reason so quarantined packages are not misreported as unknown;
keep check_pypi_quarantine_status semantics unchanged at the resolution entry
points.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 72cf8f67-18ca-4c6c-8848-8044e83d0c4d

📥 Commits

Reviewing files that changed from the base of the PR and between 06e6317 and 445f9b6.

📒 Files selected for processing (3)

• src/fromager/resolver.py
• src/fromager/sources.py
• tests/test_resolver.py