Python: fix dependency maintenance cutoff

[Eduard van Valkenburg (eavanvalkenburg)]

Motivation & Context

The scheduled Python dependency maintenance workflow failed before it could create dependency updates because the release cutoff was exported as UV_EXCLUDE_NEWER for the entire job. That global uv setting made the already-pinned dev environment unsatisfiable whenever a current dependency pin, such as prek==0.4.5, was newer than the cutoff.

This keeps the workflow able to resolve the current workspace while still delaying automated dependency update candidates until they are older than the cutoff.

Description & Review Guide

• What are the major changes? Replace the job-wide UV_EXCLUDE_NEWER export with DEPENDENCY_RELEASE_CUTOFF, have the dependency candidate catalog read that value, and make dev-pin refresh avoid downgrades when the cutoff excludes the current pin.
• What is the impact of these changes? Newly added or already-pinned dependencies can be resolved immediately, but maintenance updates still wait for the cutoff window. The dev-pin refresh also avoids known incompatible updates such as bumping opentelemetry-sdk while azure-monitor-opentelemetry pins it.
• What do you want reviewers to focus on? Whether the cutoff is now scoped correctly to update candidate selection rather than uv environment resolution.

Related Issue

No linked issue; this fixes a scheduled workflow failure observed in Python dependency maintenance.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

This PR fixes the Python dependency maintenance workflow by decoupling the “release cutoff” concept from uv’s global resolver behavior, so the workflow can still resolve the current pinned workspace while only applying the cutoff to dependency update candidate selection.

Changes:

• Replace the workflow’s job-wide UV_EXCLUDE_NEWER export with a dedicated DEPENDENCY_RELEASE_CUTOFF environment variable.
• Update dependency bounds scripts to read DEPENDENCY_RELEASE_CUTOFF (with backward-compatible fallback to UV_EXCLUDE_NEWER).
• Prevent dev-pin refresh from downgrading an already-pinned dependency when the cutoff would otherwise exclude the current pin; add a guard to avoid updating opentelemetry-sdk when azure-monitor-opentelemetry is present.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
python/scripts/dependencies/_dependency_bounds_upper_impl.py	Reads the new cutoff env var; refines dev pin repinning to avoid cutoff-driven downgrades and an otel-specific incompatible bump scenario.
python/scripts/dependencies/_dependency_bounds_lower_impl.py	Reads the new cutoff env var (fallback maintained for legacy behavior).
.github/workflows/python-dependency-maintenance.yml	Stops exporting UV_EXCLUDE_NEWER globally; exports DEPENDENCY_RELEASE_CUTOFF instead.

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 91%

✓ Correctness

The PR correctly scopes the dependency release cutoff to candidate selection (via DEPENDENCY_RELEASE_CUTOFF) instead of applying it globally to uv resolution (via UV_EXCLUDE_NEWER). The env var fallback maintains backward compatibility. The downgrade prevention logic in _collect_dev_pin_replacements is correct: it skips updates when the cutoff-filtered latest version is older than the current pin, and the lockfile fallback for non-pinned deps preserves stability. The opentelemetry-sdk special case is a reasonable hardcoded guard against known incompatibilities. No correctness issues found.

✓ Security Reliability

The changes correctly scope the release cutoff to dependency candidate selection rather than global uv resolution. The env var reading maintains backward compatibility by falling back to UV_EXCLUDE_NEWER. Date parsing is properly guarded with try/except. The new downgrade prevention and opentelemetry-sdk pining logic handle edge cases safely with appropriate None checks. No security or reliability issues identified.

✓ Test Coverage

This PR introduces several new logic paths — _exact_pin_version(), downgrade prevention, lockfile fallback for unpinned deps, and an OpenTelemetry-specific skip rule — but adds no unit tests. The scripts/dependencies directory has no test infrastructure at all. While the PR checklist acknowledges tests were not added ('All unit tests pass, and I have added new tests where possible' is unchecked), the new pure-function helper _exact_pin_version and the conditional logic branches are highly amenable to unit testing and would reduce regression risk for this maintenance-critical workflow.

✓ Failure Modes

This PR cleanly scopes the release cutoff to dependency candidate selection rather than global uv resolution. The env var change maintains backward compatibility via an or fallback. The new downgrade protection, lock fallback logic, and otel special-casing are all defensive and appropriately logged. I found no concrete silent failure paths, lost errors, or operational failure modes introduced by these changes.

✗ Design Approach

I found one design issue in the new dev-pin selection logic. The workflow correctly stops exporting UV_EXCLUDE_NEWER job-wide, but _collect_dev_pin_replacements() now unconditionally falls back to the current lockfile for any non-exact dev requirement, which means ranged dev dependencies stop following the configured version source and can no longer be advanced by the maintenance run until something else updates uv.lock first.

Flagged Issues

• python/scripts/dependencies/_dependency_bounds_upper_impl.py now forces every non-exact dev requirement to use catalog.get_lock(...) instead of the selected source. Because the workflow runs upgrade-dev-dependency-pins before uv lock --upgrade, ranged requirements like rich>=13.7.1,<16.0.0 will always be pinned to the old lockfile version rather than the newest candidate, contradicting the script's own 'selected version source' contract. The lockfile fallback should be scoped to the exact-pin downgrade case only.

Suggestions

• The env-var fallback change (DEPENDENCY_RELEASE_CUTOFF or UV_EXCLUDE_NEWER) appears in two files (_dependency_bounds_lower_impl.py:391 and _dependency_bounds_upper_impl.py:537). A simple parametrized test confirming precedence (new var wins, old var still works, neither returns None) would document the contract and prevent future regressions.

---

Automated review by eavanvalkenburg's agents

[github-actions]

Flagged issue

python/scripts/dependencies/_dependency_bounds_upper_impl.py now forces every non-exact dev requirement to use catalog.get_lock(...) instead of the selected source. Because the workflow runs upgrade-dev-dependency-pins before uv lock --upgrade, ranged requirements like rich>=13.7.1,<16.0.0 will always be pinned to the old lockfile version rather than the newest candidate, contradicting the script's own 'selected version source' contract. The lockfile fallback should be scoped to the exact-pin downgrade case only.

---

Source: automated DevFlow PR review

[github-actions]

Python Test Coverage Report •

File	Stmts	Miss	Cover	Missing
packages/hyperlight/agent_framework_hyperlight
_execute_code_tool.py	620	93	85%	69, 175, 238, 270, 273, 308–309, 324, 326, 339, 357, 367, 392, 397, 404, 410, 418, 426–428, 430–435, 475, 480, 482, 484, 509–510, 516–517, 522–523, 542–543, 552–553, 588, 619, 625–628, 646–649, 657, 690–691, 698–699, 701, 711–712, 752–753, 760, 806, 862–868, 937, 964, 1034, 1070, 1076–1078, 1107–1111, 1115–1116, 1121, 1138–1142, 1146–1147, 1204–1205
TOTAL	40634	4626	88%

Python Unit Test Overview

Tests	Skipped	Failures	Errors	Time
8098	34 💤	0 ❌	0 🔥	2m 10s ⏱️