You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The split pin for fonttools by Python version is applied here; confirm all build/test images actually run with the intended Python versions so the correct pin (4.59.0 for <3.10, 4.61.0 for >=3.10) is selected consistently.
The software-properties-common install now uses || true. Verify that later build steps do not rely on tools from this package; otherwise failures could be masked on Debian.
# Install software-properties-common if available (Ubuntu-specific, optional on Debian)
RUN apt-get update && apt-get install --no-install-recommends -y software-properties-common || true \
&& rm -rf /var/lib/apt/lists/*
mlflow==2.22.4 is pinned and fonttools is split by Python version; verify downstream locked requirement files and images remain in sync and no transitive dependency conflicts arise with matplotlib or mlflow extras.
Removing the Python version marker can introduce incompatible pins for non-3.11 runtimes if any exist. Ensure your GPU image actually runs only on the supported Python version, or restore markers for packages known to differ by Python version to prevent resolution/install failures.
Why: Line 254 changes bokeh by removing the Python marker; reintroducing the marker can prevent cross-version incompatibilities, though impact depends on supported runtimes.
Medium
Keep per-Python wheels split
Consolidating contourpy to a single pin across Python versions may lead to binary wheel incompatibilities, especially for older minor versions. Restore the per-version pins to avoid import/runtime errors in environments not matching the wheel build tags.
Why: Lines 488-491 consolidate contourpy; keeping per-version pins can avoid wheel/ABI issues across Python versions, improving robustness for mixed environments.
Medium
Preserve interpreter-specific grpc pins
Unifying grpcio-tools across Python versions can break code generation due to pinned protobuf/ABI mismatches on older interpreters. If you support multiple Python versions, keep version-conditional pins aligned with upstream compatibility matrices.
Why: Lines 1187-1190 introduce unconditional grpcio-tools; recommending version-conditional pins aligns with prior diff context and can prevent protobuf/ABI mismatches across interpreters.
Medium
Avoid hard Python-version pin
Pinning to --python-version 3.11 in the lock command can break builds on different Python runtimes used by your images or CI. If your targets include other Python versions, remove the hard pin or generate per-Python lock files to prevent resolver mismatches and runtime incompatibilities.
Why: The existing line with --python-version 3.11 is present at line 2 and the advice to avoid hard-pinning can improve portability across runtimes, though it depends on project policy and is not strictly a bug fix.
Low
Restore version markers for compatibility
Consolidating click to a single version may break environments previously constrained by Python markers (e.g., <3.10). If you still build images for older Python, reintroduce markers or ensure click==8.3.1 supports all targeted runtimes to avoid import/runtime failures.
Why: The unified click==8.3.1 is at lines 518-520; reintroducing markers could prevent breakage on older Pythons if still supported. Useful but contingent on supported Python matrix.
Low
Align lockfile Python compatibility
Pinning the lockfile to Python 3.11 in the generation command may produce wheels incompatible with other Python minors/patches used by your GPU image matrix. Verify that all runtime images use Python 3.11 exactly, or regenerate per-target Python version. Otherwise, builds on differing Python versions can break at install time.
Why: The line at 2 adds a generation command pinned to Python 3.11; suggesting verification or broader pin (3.11.*) is reasonable but not critical, and it's an advisement rather than a precise fix.
Low
Reintroduce version-split dependency
You removed the split pins by Python version. If any downstream dependency expects click <8.2 on older interpreters, this can break CLI entry points. Re-add the version markers to match interpreter constraints or confirm all environments use the newer-compatible Python.
Why: At lines 459-461, click is unconditionally pinned; restoring version-split could help multi-Python support, but if project standardizes on newer Python this may be unnecessary.
Low
Reinstate ABI safety marker
Dropping the Python version marker can cause installation of incompatible wheels on unsupported Python versions. If non-3.11 environments are still built or used, re-add the marker to ensure correct ABI-matching wheels.
Why: Line 1504 removes the Python marker for lz4; re-adding the marker can prevent incompatible wheel installs if non-3.11 environments are still targeted.
Low
General
Validate conditional dependency marker
The environment marker excludes Python >3.11.2, but upstream aiohttp previously depended on async-timeout. Since you upgraded aiohttp to 3.13.2, ensure no remaining consumers need this conditional to avoid runtime import errors on newer Python. Align or remove the marker based on actual deps.
async-timeout==5.0.1 ; python_full_version <= '3.11.2' \
--hash=sha256:39e3809566ff85354557ec2398b55e096c8364bacac9405a7a1fa429e77fe76c \
--hash=sha256:d9321a7a3d5a6a5e187e824d2fa0793ce379a202935782d555d6e9d2735677d3
- # via redis+ # via+ # redis+ # (verify no aiohttp path requires it; remove marker/package if unused)
Suggestion importance[1-10]: 5
__
Why: The snippet with the environment marker appears (lines 238-241) and advising verification after upgrading aiohttp is sensible, but it’s an ensure/verify suggestion without actionable change.
Low
Ensure stable CA bundle version
Jumping to a future-dated certifi can cause SSL trust discrepancies with system cert stores in some base images. Verify TLS handshake behavior against your services; if issues arise, revert to a widely tested current release for stability.
Why: The certifi==2025.11.12 pin is at lines 317-319; recommending a revert for stability is cautious but speculative without concrete incompatibility evidence.
Low
Verify async stack compatibility
aiohttp 3.13 changed some behaviors and dropped past async-timeout coupling; ensure downstream packages (e.g., aiobotocore, aioitertools) remain compatible. If you observe runtime or type errors, consider pinning compatible minors across this async stack to avoid subtle event-loop issues.
Why: The aiohttp==3.13.2 block is at lines 17-137 and noting potential compatibility issues across async deps is prudent, but it largely asks to verify and doesn’t pinpoint a concrete issue in the diff.
Low
Security
Remove unnecessary new dependency
Introducing annotated-doc adds a new transitive dependency path to your API surface. Verify this package is actually required by your fastapi version; if not strictly needed, remove it from the lock to reduce supply-chain and compatibility risk.
-annotated-doc==0.0.4 \- --hash=sha256:571ac1dc6991c450b25a9c2d84a3705e2ae7a53467b5d111c24fa8baabbed320 \- --hash=sha256:fbcda96e87e9c92ad167c2e53839e57503ecfda18804ea28102353485033faa4- # via fastapi+# (Remove the annotated-doc block entirely if FastAPI does not require it)
Suggestion importance[1-10]: 4
__
Why: The annotated-doc block exists at lines 181-184, and the suggestion to verify necessity is reasonable but speculative and provides no concrete evidence it’s unnecessary; moderate impact at best.
Reintroducing unconditional pins (removing environment markers) can produce incompatible installs if this lock is reused on unsupported Python versions. Ensure this file is only consumed in Python versions compatible with all unconditional pins, or retain markers for packages with Python-specific wheels.
Why: The PR removed the python_full_version marker for bokeh; reinstating environment guards could avoid incompatibility on unsupported Pythons if this lock is reused beyond 3.11.
Medium
Maintain version-split for compatibility
Removing the Python-specific split to a single click pin risks incompatibility on older images. If the GPU image or downstream tools may run under varied Python versions, keep version markers to prevent resolver conflicts and runtime errors.
Why: The PR consolidates click to a single pin; restoring split markers can prevent incompatibilities on older Python, assuming multi-Python usage of the lock.
Medium
Re-add Python-aware contourpy pins
contourpy wheels differ by Python version; making this unconditional can break installs on unsupported Pythons. Reinstate markers so the resolver selects a compatible build for each Python.
Why: The PR collapsed multiple contourpy pins into one; reintroducing markers helps ensure wheel availability across Python versions if needed.
Medium
Sync dask stack with markers
Align dask/distributed pins with Python markers if multiple Python versions are in scope. Mixed unconditional pins may select wheels unsupported by older Pythons, causing install or runtime failures.
Why: dask/distributed were unified to unconditional pins; adding markers maintains compatibility for older Python environments if the lock is reused.
Medium
Remove hardcoded Python version
Avoid pinning a specific Python minor version in the lock-generation command comment unless the runtime is guaranteed to be 3.11. If images are ever built with a different Python, resolution may mismatch and produce incompatible wheels. Reflect the actual build Python or remove the flag to prevent drift.
Why: The existing code at line 2 pins --python-version 3.11 in the generation comment; recommending removal can prevent drift if builds vary, but it's context-dependent and not critical.
Low
Guard lz4 by Python version
lz4 provides wheels that may not exist for all Python minors; removing the Python guard risks build-from-source or failures. Add back the marker to ensure only supported Python variants consume this pin.
Why: The PR removed the python version guard for lz4; restoring it can reduce risk of missing wheels on older Python, though impact depends on supported Python scope.
Low
Restore version-guarded click pins
Merging multiple click pins into a single unguarded pin can break consumers that previously relied on version-specific markers. Reintroduce environment markers if different Python versions are supported to prevent incompatible resolution at build time.
Why: The existing unified click==8.3.1 is present at those lines; the suggestion to restore version markers could help multi-Python environments but isn't clearly required by this PR and reintroduces older versions without evidence.
Low
General
Avoid hardcoding Python version
Locking with a fixed --python-version 3.11 may produce wheels incompatible with other interpreter versions used by your images. If multi-Python builds are expected, regenerate per-target locks or drop the explicit flag to match the actual build runtime.
Why: The comment line exactly matches and advising against --python-version 3.11 can improve portability; however, it's a process/config note rather than a concrete code bug.
Low
Narrow environment marker scope
Since aiohttp==3.13.2 is now pinned, async-timeout should not be pulled for aiohttp on Python 3.11+. Keep the marker restricted to avoid unnecessary backports and conflicts. Verify no other dependency (besides redis) requires async-timeout; otherwise, consider scoping it further.
-async-timeout==5.0.1 ; python_full_version <= '3.11.2' \+async-timeout==5.0.1 ; python_full_version <= '3.11.2' and extra == "redis" \
--hash=sha256:39e3809566ff85354557ec2398b55e096c8364bacac9405a7a1fa429e77fe76c \
--hash=sha256:d9321a7a3d5a6a5e187e824d2fa0793ce379a202935782d555d6e9d2735677d3
# via redis
Suggestion importance[1-10]: 4
__
Why: The snippet matches the new hunk and the rationale (aiohttp 3.13+ not needing async-timeout) is reasonable, but adding an extra marker extra == "redis" is not grounded in the lockfile context and may be incorrect; suggests verification rather than a precise fix.
Low
Avoid unnecessary transitive pins
New transitive fastapi dependency pin can introduce ABI or API shifts. Confirm this package is intended and compatible; if not required, avoid pinning it to reduce surface area and potential conflicts.
-annotated-doc==0.0.4 \- --hash=sha256:571ac1dc6991c450b25a9c2d84a3705e2ae7a53467b5d111c24fa8baabbed320 \- --hash=sha256:fbcda96e87e9c92ad167c2e53839e57503ecfda18804ea28102353485033faa4- # via fastapi+# annotated-doc is a transitive dependency of fastapi; pin only if explicitly required+# annotated-doc==0.0.4 \+# --hash=sha256:571ac1dc6991c450b25a9c2d84a3705e2ae7a53467b5d111c24fa8baabbed320 \+# --hash=sha256:fbcda96e87e9c92ad167c2e53839e57503ecfda18804ea28102353485033faa4+# # via fastapi
Suggestion importance[1-10]: 3
__
Why: The lines exist and adding annotated-doc may be unnecessary, but removing a pinned transitive from a lockfile undermines reproducibility; the advice is cautious and low impact.
Pinning mlflow here while also pinning it in extras-requirements.txt risks version drift between images and extras, causing runtime incompatibilities. Consolidate the mlflow pin to a single source or ensure both locations use exactly the same constraint via a shared include.
mlrun-pipelines-kfp-v1-8~=0.5.7
grpcio~=1.70.0
fonttools==4.61.0
-mlflow==2.22.4+# mlflow pinned in extras-requirements.txt to a single source of truth
Suggestion importance[1-10]: 7
__
Why: Correctly identifies duplicate pinning of mlflow across files which can drift; consolidating improves maintainability though it’s advisory rather than a concrete bug fix.
Medium
Validate hard pin compatibility
Pinning mlflow exactly may conflict with transitive constraints from the locked requirements in production images. If a hard pin is required, verify all dependent integrations (e.g., tracking server, SQLAlchemy, alembic) match this version, or consider a compatible range to reduce breakage risk.
-mlflow==2.22.4+mlflow==2.22.4 # ensure compatibility with alembic/sqlalchemy versions across images
Suggestion importance[1-10]: 6
__
Why: Sensible caution about locking mlflow==2.22.4 and its dependencies; it’s accurate and relevant but primarily a verification note with limited immediate impact.
Low
Check alembic compatibility
Upgrading alembic can introduce migration API changes; ensure the pinned mlflow version’s SQLAlchemy/alembic compatibility matrix is satisfied to prevent migration failures at startup. Run a migration dry-run in CI.
alembic==1.17.2 \
--hash=sha256:bbe9751705c5e0f14877f02d46c53d10885e377e3d90eda810a016f9baa19e8e \
--hash=sha256:f483dd1fe93f6c5d49217055e4d15b905b425b6af906746abb35b69c1996c4e6
+# Confirm compatibility with mlflow==2.22.4 and SQLAlchemy versions
Suggestion importance[1-10]: 6
__
Why: Advises verifying alembic upgrade compatibility with mlflow/SQLAlchemy; relevant and prudent though mostly a CI/process check.
Low
Verify TLS store compatibility
The lock pins certifi to a future-dated release; ensure your base OS trust store and requests/urllib3 stacks are compatible to avoid SSL verification mismatches. If build images lack CA updates, this can break outbound TLS.
certifi==2025.11.12 \
--hash=sha256:97de8790030bbd5c2d96b7ec782fc2f7820ef8dba6db909ccf95449f2d062d4b \
--hash=sha256:d8ab5478f2ecd78af242878415affce761ca6bc54a22a27e026d7c25357c3316
+# Verify TLS chain with base image CA store to prevent SSL errors
Suggestion importance[1-10]: 5
__
Why: The note about certifi potentially mismatching OS trust stores is reasonable and relevant, but it’s an operational check rather than a code issue.
Low
Reconfirm conditional dependency need
aiohttp 3.13 no longer requires async-timeout on modern Python, but your conditional pin remains. Confirm your runtime Python version; if >3.11.2, this extra may be unnecessary and could cause dependency resolution issues.
Using --overrides can force versions conflicting with transitive constraints, potentially breaking reproducible builds. Ensure the override file is minimal and only includes intentional pins; otherwise drop the flag to respect upstream constraints.
Why: Advising caution with --overrides is relevant given the PR adds it; it’s a valid maintenance consideration, though it’s a recommendation rather than a concrete bug fix.
Low
Avoid overly strict mlflow pin
Strictly pinning mlflow==3.2.0 while enabling overrides in the lock process can cause conflicts with plugins or providers expecting newer mlflow APIs. Use a compatible range to avoid resolver breaks and ABI/API mismatches.
Why: Using a range for mlflow may ease compatibility with plugins, but the PR intentionally pins versions and no concrete conflict is shown; it's a reasonable but non-critical improvement.
Low
Clarify override consistency note
Documenting --overrides in the lock header while also pinning strict versions can lead to non-reproducible locks if overrides drift. Add a note to keep override and requirements pins consistent to avoid resolver conflicts.
# uv pip compile requirements.txt extras-requirements.txt dockerfiles/mlrun-api/requirements.txt --overrides dockerfiles/mlrun-api/requirements.txt --python-version 3.11 --output-file dockerfiles/mlrun-api/locked-requirements.txt
+# NOTE: Keep dockerfiles/mlrun-api/requirements.txt pins minimal and consistent with overrides to prevent resolver conflicts.
Suggestion importance[1-10]: 3
__
Why: Adding a note improves documentation but offers minimal functional impact; also, guidelines disallow high scores for comment-only changes.
Low
Possible issue
Relax strict version pin
Pinning fonttools==4.61.0 may be too old for transitive dependencies (e.g., Matplotlib or Pillow) often requiring newer fonttools, causing install or runtime conflicts. Consider a compatible range to reduce resolver failures.
Why: The suggestion to relax fonttools==4.61.0 to a compatible range could reduce resolver conflicts, but it's speculative without evidence from this PR; impact is moderate and context-dependent.
Ensure the --overrides flag matches the actual file name expected by uv (singular --override in some versions). A mismatched flag can silently be ignored, producing an incorrect lock.
Why: This points out a potential mismatch in uv CLI flags shown in the autogenerated header; correctness depends on uv version, but using the wrong flag could indeed yield an incorrect lock.
Medium
Fix uv flag spelling
Verify the correct uv flag spelling; many uv versions expect --override (singular). Using an unrecognized flag can result in overrides not applied, yielding a bad lock file.
Why: The Makefile line uses --overrides; if the tool expects --override, overrides may be ignored, making this potentially impactful though version-dependent.
Medium
General
Align mlflow constraints
A hard pin to mlflow==3.2.0 can drift from dependencies.py which specifies ~3.2. Align the constraint to avoid environment divergence between installations.
Why: Aligning mlflow constraints between files reduces divergence risk; it correctly references the new pin and suggests a compatible range consistent with dependencies.py.
Low
Narrow the mlflow version range
Bumping mlflow to ~3.2 may introduce incompatible API or dependency changes versus the rest of your stack. Consider scoping this upgrade to a narrower patch range until compatibility is verified.
Why: The suggestion correctly references the added mlflow constraint and proposes narrowing to patch-level; it's a reasonable caution but not strictly necessary without evidence of incompatibility.
Low
Relax strict fonttools pin
Pinning fonttools may conflict with transitive deps (e.g., matplotlib) and restrict security updates. Prefer a compatible range to reduce breakage risk unless exact pin is required.
Why: Relaxing an exact pin could reduce conflicts but may also introduce variability; it's a style/maintainability improvement with moderate impact and context-dependent.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Type
Enhancement
Description
Pin mlflow to 2.22.4 everywhere
Pin fonttools by Python version
Regenerate locks with python-version hints
Improve Debian install robustness in test image
Diagram Walkthrough
File Walkthrough
9 files
Update mlflow and fonttools pins and hashesAdd python-version compile hint, split fonttools pins, bump mlflowAdd python-version compile hint, split fonttools pins, bump mlflowSplit fonttools pins by Python and bump mlflowAdd fonttools version split and pin mlflowPin mlflow to 2.22.4 in API serviceAlign dependency locks with mlflow and fonttools pinsRefresh locks with mlflow 2.22.4 and fonttools rulesUpdate locked dependencies to new pins1 files
Install software-properties-common optionally on Debian