feat: add package registry and maintainability check (#1400) by RuchitAgrawal · Pull Request #1403 · oracle/macaron

RuchitAgrawal · 2026-05-02T13:14:23Z

Summary

Adds a new check mcn_registry_maintainability_1 that validates whether a package exists on its public registry and is actively maintained.

Description of changes

The check uses three signals when available:

Registry presence and release recency: Uses the existing find_publish_timestamp() to confirm the package exists and check how many days have passed since the last release. Exceeding the threshold fails the check.
Deprecated/yanked status: Reads the yanked flag for PyPI packages and the deprecated field for npm packages from existing registry JSON responses. A yanked or deprecated package always fails, regardless of release age.
GitHub repository signals: If the source repo is on GitHub, calls the existing get_repo_data() to check if the repo is archived and how recently code was pushed. An archived repo always fails.

Results include remediation guidance and links to the registry page and source repository. The inactivity threshold is configurable via defaults.ini under registry_maintainability (default: 365 days).

Related issues

Closes #1400

Checklist

I have reviewed the contribution guide.
My PR title and commits follow the Conventional Commits convention.
My commits include the "Signed-off-by" line.
I have signed my commits following the instructions provided by GitHub. Note that we run GitHub's commit verification tool to check the commit signatures. A green verified label should appear next to all of your commits on GitHub.
I have updated the relevant documentation, if applicable.
I have tested my changes and verified they work as expected.

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

behnazh-w · 2026-05-05T05:59:12Z

@RuchitAgrawal Thanks for the PR! Could you suggest a few packages that would fail this check? That would help us identify good candidates to include in integration tests.

behnazh-w · 2026-05-05T07:06:37Z

@RuchitAgrawal Looks like the integration tests are failing. You can search for "case failed" in the log to see which test is failing.

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

RuchitAgrawal · 2026-05-07T15:56:35Z

Thanks for the PR! Could you suggest a few packages that would fail this check? That would help us identify good candidates to include in integration tests.

@behnazh-w ,Here are a few packages that would fail across the check evaluation:

pkg:pypi/aiohttp@3.9.3 — yanked due to a security vulnerability
Stale release (last release older than the default 365-day threshold):
pkg:pypi/arrow@0.15.0 — released May 2019, ~7 years old
pkg:pypi/boto@2.49.0 — released April 2018, the original boto library superseded by boto3
pkg:npm/request@2.88.2 — officially deprecated in 2020

RuchitAgrawal · 2026-05-07T15:58:19Z

@RuchitAgrawal Looks like the integration tests are failing. You can search for "case failed" in the log to see which test is failing.

Found the issue and pushed a fix.

behnazh-w · 2026-05-14T00:00:29Z

Thanks for the PR! Could you suggest a few packages that would fail this check? That would help us identify good candidates to include in integration tests.

@behnazh-w ,Here are a few packages that would fail across the check evaluation:
* pkg:pypi/aiohttp@3.9.3 — yanked due to a security vulnerability
  Stale release (last release older than the default 365-day threshold):

* pkg:pypi/arrow@0.15.0 — released May 2019, ~7 years old

* pkg:pypi/boto@2.49.0 — released April 2018, the original boto library superseded by boto3

* pkg:npm/request@2.88.2 — officially deprecated in 2020

Thanks a lot. For pkg:pypi/arrow@0.15.0 we already have an integration test and can make sure that the check explicitly fails.

For the rest, we can add new integration tests since each test can cover a different scenario or failure reason.

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

RuchitAgrawal · 2026-05-15T14:34:04Z

@behnazh-w Thanks for the feedback! I've added the integration tests as suggested. Here is what was done:

Extended the existing pypi_arrow to also check mcn_registry_maintainability_1: fails for arrow@0.15.0 and passes for arrow@1.3.0.
Added pypi_aiohttp: covers the yanked package path (aiohttp@3.9.3).
Added pypi_boto: covers the stale release path (boto@2.49.0).
Added npm_request: covers the npm deprecated path (request@2.88.2).

All three new tests follow the same pattern i.e. the policy requires the check to pass, but since it correctly fails for these packages, we set expect_fail: true.

Regarding the CI failures visible on the PR, those build tests were already failing on main before this PR . These changes don't touch any of those test cases.

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

RuchitAgrawal · 2026-05-19T12:37:29Z

Hi @behnazh-w, Out of the 18 failing tests, 1 was pypi_arrow which was failing because of my last commit.

The problem was I applied the registry-maintainability policy to all arrow versions using a wildcard, assuming arrow@1.3.0 would pass. Fixed it in the latest commit, by scoping the policy to only arrow@0.15.0.
Kindly review the PR again.

behnazh-w · 2026-05-20T06:35:08Z

+
+        # Confirm registry presence and retrieve last release date.
+        try:
+            publish_dt: datetime = registry_info.package_registry.find_publish_timestamp(


The “release recency” signal checks the analyzed PURL version’s publish date, not the package’s latest release date. That means an old pinned version of an actively maintained package fails as “unmaintained,” and last_release_date is misleading.

Added a _get_latest_release_timestamp helper that fetches the latest release date of the package. For PyPI, it reuses the cached package-level JSON and calls get_latest_release_upload_time(). For npm, it calls get_latest_version() then queries deps.dev for that version's timestamp. This is now what drives days_since_release and last_release_date, with the specific version's timestamp as a fallback.

behnazh-w · 2026-05-20T06:44:19Z

+        return urllib.parse.urljoin(pkg_registry.registry_url, f"project/{name}/{version}/")
+
+    if isinstance(pkg_registry, NPMRegistry):
+        return f"https://www.npmjs.com/package/{name}/v/{version}"


npm scoped package URLs omit the namespace. For pkg:npm/@scope/name@1.0.0, the report link becomes /package/name/v/1.0.0 instead of /package/@scope/name/v/1.0.0.

You could instead check the namespace first:

package_name = f"{namespace}/{name}" if namespace else name return f"https://www.npmjs.com/package/{package_name}/v/{version}"

Fixed by adding namespace as a parameter to _build_registry_url and constructing the npm URL as f"{namespace}/{name}" when a namespace is present, so scoped packages like @scope/name generate the correct link.

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

RuchitAgrawal · 2026-05-21T09:06:50Z

@behnazh-w Thanks for reviewing the PR. I have addressed all the comments in the latest commit. Kindly take another look when you get a chance.

feat: add package registry and maintainability check (oracle#1400)

05cc967

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

RuchitAgrawal requested a review from behnazh-w as a code owner May 2, 2026 13:14

oracle-contributor-agreement Bot added the OCA Verified All contributors have signed the Oracle Contributor Agreement. label May 2, 2026

RuchitAgrawal added 2 commits May 7, 2026 15:46

fix: revert pypi_arrow policy and fix flake8 line length

e0af677

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

Merge branch 'main' into feat/1400-add-registry-and-heath-check

f92a904

test: add integration tests for mcn_registry_maintainability_1

37f557f

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

RuchitAgrawal added 2 commits May 15, 2026 21:07

Merge branch 'main' into feat/1400-add-registry-and-heath-check

659f1f9

test: fix pypi_arrow registry-maintainability policy

7cb72f0

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

behnazh-w reviewed May 20, 2026

View reviewed changes

fix: changes made according suggestions by reviewer

520aef7

Signed-off-by: ruchitagrawal <rragrawal16@gmail.com>

Conversation

RuchitAgrawal commented May 2, 2026

Summary

Description of changes

Related issues

Checklist

Uh oh!

behnazh-w commented May 5, 2026

Uh oh!

behnazh-w commented May 5, 2026

Uh oh!

RuchitAgrawal commented May 7, 2026

Uh oh!

RuchitAgrawal commented May 7, 2026

Uh oh!

behnazh-w commented May 14, 2026

Uh oh!

RuchitAgrawal commented May 15, 2026

Uh oh!

RuchitAgrawal commented May 19, 2026

Uh oh!

Uh oh!

Uh oh!

behnazh-w May 20, 2026

Choose a reason for hiding this comment

Uh oh!

RuchitAgrawal May 21, 2026

Choose a reason for hiding this comment

Uh oh!

behnazh-w May 20, 2026

Choose a reason for hiding this comment

Uh oh!

RuchitAgrawal May 21, 2026

Choose a reason for hiding this comment

Uh oh!

RuchitAgrawal commented May 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants