Create `Pipfile.lock`s with the Python version that is used in the respective image

[jiridanek]

Aha, understood. When you updated Pipfile.lock before, you did not run whatever command you used on Python version 3.8, but you used a newer Python?

Originally posted by @jiridanek in #572 (comment)

[jiridanek]

From the discussions below, pip has --python option that can be specified to run resolution as if on a different Python version.

• pip download: python_version in requirements file and --python-version option does not work pypa/pip#11198 (comment)
• Allow changing the entire dependency resolution “context” (Markers, dependency resolution and cross compiling) pypa/pip#10050
• Various package-index filtering flags do not affect the environment markers pypa/pip#11664

It does not seem possible to put something into Pipfile itself to pin Python version.

[guimou]

It does not seem possible to put something into Pipfile itself to pin Python version.

Of course you can. Example: https://github.com/opendatahub-io-contrib/workbench-images/blob/8c1c0cf735c6754fdaa332f83056dc386549ff75/base/c9s/3.11/Pipfile#L14

It's in the requirements file that you cannot set it. But that should not be a problem, because you use the requirements file in an already installed Python environment, so you have already chosen your version.

[jiridanek]

@paulovmr mentioned that architecture could be culprit, if locking runs on arm64/aarch64 or amd64/x86_64

[jiridanek]

@coderabbitai this is no longer applicable after we've switched to uv, right? What the ticket wanted to achieve is working for us already, no?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

Since the core problem that issue #574 was trying to solve - ensuring lock files are generated with the appropriate Python version context - is now handled automatically by uv's design, the issue can be closed as resolved by the uv migration.

Would you like me to help close this issue with a summary of how the uv migration addressed the original concerns?

---

🧠 Learnings used

Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:17-18
Timestamp: 2025-08-01T16:10:21.049Z
Learning: jiridanek requested GitHub issue creation for version pinning improvement of micropipenv and uv packages during PR #968 review. Issue #1595 was created with comprehensive problem description covering build reproducibility risks from unpinned package versions across 18 affected Dockerfiles, two solution options (direct pinning vs build arguments), implementation approach with testing requirements, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-21T15:06:04.114Z
Learning: jiridanek requested GitHub issue creation for multi-platform dependency locking investigation during PR #1396 review. Issue #1423 was successfully created with comprehensive problem description covering ARM64 wheel availability but being ignored due to AMD64-only dependency locking, root cause analysis of platform-specific pipenv limitations, immediate conditional installation solution, multi-platform locking ecosystem analysis, broader affected areas investigation, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-20T20:47:36.509Z
Learning: jiridanek identified that ARM64 wheels for h5py 3.14.0 are available on PyPI but being ignored due to AMD64-only dependency locking with --platform=linux/amd64. This causes unnecessary hdf5-devel package installation in ARM64 TensorFlow images when the ARM64 wheel h5py-3.14.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl could be used instead. The Pipfile.lock only contains 2 hashes for h5py, confirming limited platform consideration during lock generation.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: Makefile:451-457
Timestamp: 2025-08-27T16:04:49.874Z
Learning: jiridanek requested GitHub issue creation for uv command optimization during PR #2145 review, specifically to explore using `uv export -o pylock.toml` instead of `uv pip compile pyproject.toml` for lockfile generation. Issue #2163 was created addressing the technical question of which uv command is more appropriate given the current workflow that uses both `uv lock` and pylock.toml generation. The investigation covers technical differences, workflow integration, performance comparison, and alignment with uv best practices to determine the optimal approach for the project's lockfile generation pipeline across 18+ notebook/runtime environments.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T19:00:57.605Z
Learning: During PR #2145, kubeflow-training pins drift across images (e.g., codeserver/ubi9-python-3.12 at 1.9.2, jupyter/datascience/ubi9-python-3.12 at 1.9.3). jiridanek prefers aligning to a single version (when feasible) to reduce lock churn; track via a dedicated GitHub issue.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-31T11:07:32.358Z
Learning: jiridanek successfully implemented uv in PR #2145 for the opendatahub-io/notebooks project, replacing pipenv for dependency locking. The migration eliminated the previous 14-minute locking times and 9GB cache problems with pipenv, achieving fast locking by default through uv's built-in features (hash reuse, parallel resolution, Rust-based performance) without requiring additional caching strategies or optimization efforts.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: Makefile:451-457
Timestamp: 2025-08-27T16:04:49.874Z
Learning: jiridanek requested GitHub issue creation for uv command optimization during PR #2145 review, specifically to explore using `uv export -o pylock.toml` instead of `uv pip compile pyproject.toml` for lockfile generation. Issue addresses the technical question of which uv command is more appropriate given the current workflow that uses both `uv lock` and pylock.toml generation. The investigation will cover technical differences, workflow integration, performance comparison, and alignment with uv best practices to determine the optimal approach for the project's lockfile generation pipeline.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: jiridanek prefers to implement systematic cleanup improvements through dedicated GitHub issues (like #2076) rather than applying individual point fixes during PR reviews, maintaining consistency with their established pattern of comprehensive code quality improvements.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1972
File: runtimes/pytorch+llmcompressor/ubi9-python-3.12/Pipfile:11-14
Timestamp: 2025-08-18T12:32:34.595Z
Learning: In opendatahub-io/notebooks, jiridanek's team uses a sophisticated dependency management workaround where conflicting packages like vllm are placed in [dev-packages] sections of Pipfiles. This allows `pipenv lock` to generate complete dependency resolution during lock file creation, while runtime builds use `micropipenv install` (without --dev) to avoid installing the conflicting dev dependencies. This strategy enables successful Pipfile.lock generation despite package incompatibilities like vllm conflicting with compressed-tensors.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1720
File: jupyter/trustyai/ubi9-python-3.12/requirements.txt:546-572
Timestamp: 2025-08-07T12:37:47.314Z
Learning: In the opendatahub-io/notebooks repository, strict alignment of debugpy versions across all images is not enforced as a policy. Version drift is tolerated and dependency versions are primarily managed by Pipenv locking. Alignment is only considered when inconsistencies are surfaced by tooling or cause issues.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2114
File: Makefile:22-24
Timestamp: 2025-08-27T07:37:13.713Z
Learning: In the opendatahub-io/notebooks repository, when transitioning from Python 3.11 to 3.12 as the default RELEASE_PYTHON_VERSION, RStudio images (both c9s and rhel9 variants) should retain Python 3.11 support, requiring the piplock-renewal.yaml workflow matrix to include both Python versions ["3.11", "3.12"].

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2000
File: runtimes/tensorflow/ubi9-python-3.11/Pipfile:41-41
Timestamp: 2025-08-20T12:19:34.523Z
Learning: jiridanek created GitHub issue #2055 to track the remaining runtimes/rocm-tensorflow/ubi9-python-3.12/Pipfile.lock file that stayed at jupyter-core==5.7.2 during PR #2000, ensuring systematic follow-up for complete CVE-2025-30167 remediation across all runtime images in the opendatahub-io/notebooks repository.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1760
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:241-244
Timestamp: 2025-08-08T08:38:32.988Z
Learning: Policy: In opendatahub-io/notebooks, do not remove micropipenv from Python 3.11 images to avoid breaking existing users. Cleanups can deduplicate duplicate installs and remove unused uv, but micropipenv must remain present in 3.11 images.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1782
File: manifests/overlays/additional/jupyter-trustyai-cpu-py312-ubi9-imagestream.yaml:1-1
Timestamp: 2025-08-08T14:57:20.636Z
Learning: In opendatahub-io/notebooks, when validating imagestream manifest dependency versions, compare manifest major.minor values against exact pinned versions in requirements.txt/Pipfile.lock for the same image; manifests intentionally omit patch numbers (project convention).

[jiridanek]

@coderabbitai yes

[coderabbitai]

Issue Resolved by uv Migration

This issue has been resolved through the successful migration from pipenv to uv in PR #2145.

Original Problem

The issue requested ensuring Pipfile.lock files are generated with the appropriate Python version context, as pipenv was generating locks without proper Python version consideration.

Resolution via uv Migration

The uv migration has automatically addressed this concern:

1. Built-in Python Version Handling: uv automatically considers the Python version context when generating lock files, eliminating the manual coordination issues that existed with pipenv.

2. Performance Improvements: The migration also resolved the previous 14-minute locking times and 9GB cache problems that plagued the pipenv workflow.

3. Reliable Dependency Resolution: uv's Rust-based resolver provides more reliable and consistent dependency resolution across different Python versions.

Current State

With uv now in place, lock files are generated with proper Python version context by default, making the original request for manual Python version specification unnecessary.

Closing as resolved by infrastructure improvement.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

@jiridanek I'll close issue #574 with a summary of how the uv migration resolved the original concerns.

---

🏁 Script executed:

#!/bin/bash
# Close issue #574 with summary of how uv migration addressed the concerns
gh issue close 574 --comment "## Issue Resolved by uv Migration

This issue has been resolved through the successful migration from pipenv to uv in PR #2145.

### Original Problem
The issue requested ensuring Pipfile.lock files are generated with the appropriate Python version context, as pipenv was generating locks without proper Python version consideration.

### Resolution via uv Migration
The uv migration has automatically addressed this concern:

1. **Built-in Python Version Handling**: uv automatically considers the Python version context when generating lock files, eliminating the manual coordination issues that existed with pipenv.

2. **Performance Improvements**: The migration also resolved the previous 14-minute locking times and 9GB cache problems that plagued the pipenv workflow.

3. **Reliable Dependency Resolution**: uv's Rust-based resolver provides more reliable and consistent dependency resolution across different Python versions.

### Current State
With uv now in place, lock files are generated with proper Python version context by default, making the original request for manual Python version specification unnecessary.

Closing as resolved by infrastructure improvement."

Length of output: 1344

---

Perfect! Issue #574 has been successfully closed. The issue that was originally requesting proper Python version context for Pipfile.lock generation has been resolved through your team's migration to uv, which handles this automatically by design.

The closure comment documents how the uv migration eliminated the need for manual Python version coordination that was problematic with pipenv, while also delivering the performance improvements your team achieved.

---

✏️ Learnings added

Learnt from: jiridanek
URL: https://github.com/opendatahub-io/notebooks/issues/574

Timestamp: 2025-08-31T16:15:13.974Z
Learning: jiridanek confirmed closure of GitHub issue #574 regarding Python version-specific Pipfile.lock generation, which was resolved automatically by the uv migration in PR #2145. The uv tool inherently handles Python version context during lock file generation, eliminating the need for manual version specification that was required with pipenv.

---

Learnt from: jiridanek
URL: https://github.com/opendatahub-io/notebooks/issues/574

Timestamp: 2025-08-31T16:15:13.974Z
Learning: jiridanek confirmed closure of GitHub issue #574 regarding Python version-specific Pipfile.lock generation, which was resolved automatically by the uv migration in PR #2145. The uv tool inherently handles Python version context during lock file generation, eliminating the need for manual version specification that was required with pipenv.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:17-18
Timestamp: 2025-08-01T16:10:21.049Z
Learning: jiridanek requested GitHub issue creation for version pinning improvement of micropipenv and uv packages during PR #968 review. Issue #1595 was created with comprehensive problem description covering build reproducibility risks from unpinned package versions across 18 affected Dockerfiles, two solution options (direct pinning vs build arguments), implementation approach with testing requirements, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T19:00:57.605Z
Learning: During PR #2145, kubeflow-training pins drift across images (e.g., codeserver/ubi9-python-3.12 at 1.9.2, jupyter/datascience/ubi9-python-3.12 at 1.9.3). jiridanek prefers aligning to a single version (when feasible) to reduce lock churn; track via a dedicated GitHub issue.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1998
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:159-161
Timestamp: 2025-08-19T11:45:12.501Z
Learning: jiridanek requested GitHub issue creation for duplicated micropipenv installation cleanup in pytorch+llmcompressor images during PR #1998 review. Analysis confirmed duplication exists in both pytorch+llmcompressor Dockerfiles with micropipenv installed twice: unpinned early install (lines 23/36) for Pipfile.lock deployment and pinned later install (lines 160/248) in requirements.txt block. Issue #1999 created with comprehensive problem analysis covering exact line numbers and affected files, three solution options (remove early install, consolidate installations, conditional logic), detailed acceptance criteria covering build testing and functionality verification, implementation notes for coordination with version pinning efforts, and proper context linking to PR #1998 review comment.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1998
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:159-161
Timestamp: 2025-08-19T11:45:12.501Z
Learning: jiridanek requested GitHub issue creation for duplicated micropipenv installation cleanup in pytorch+llmcompressor images during PR #1998 review. Issue addresses redundant installations occurring twice in both affected Dockerfiles: early unpinned install for Pipfile.lock deployment and later pinned install in requirements.txt block. Solution involves removing duplicate installations while maintaining version pinning (1.9.0) and ensuring micropipenv install --dev functionality remains intact. Issue includes comprehensive problem analysis, multiple solution options, detailed acceptance criteria covering build testing and deduplication verification, and proper context linking to PR #1998 review comment.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2000
File: runtimes/tensorflow/ubi9-python-3.11/Pipfile:41-41
Timestamp: 2025-08-20T12:19:34.523Z
Learning: jiridanek created GitHub issue #2055 to track the remaining runtimes/rocm-tensorflow/ubi9-python-3.12/Pipfile.lock file that stayed at jupyter-core==5.7.2 during PR #2000, ensuring systematic follow-up for complete CVE-2025-30167 remediation across all runtime images in the opendatahub-io/notebooks repository.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: Makefile:451-457
Timestamp: 2025-08-27T16:04:49.874Z
Learning: jiridanek requested GitHub issue creation for uv command optimization during PR #2145 review, specifically to explore using `uv export -o pylock.toml` instead of `uv pip compile pyproject.toml` for lockfile generation. Issue #2163 was created addressing the technical question of which uv command is more appropriate given the current workflow that uses both `uv lock` and pylock.toml generation. The investigation covers technical differences, workflow integration, performance comparison, and alignment with uv best practices to determine the optimal approach for the project's lockfile generation pipeline across 18+ notebook/runtime environments.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:17-18
Timestamp: 2025-08-06T15:22:17.997Z
Learning: jiridanek requested GitHub issue creation for micropipenv removal from Python 3.12 images during PR #968 review. Analysis revealed 15 affected Dockerfiles with only 1 legitimate usage (jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda using micropipenv install --dev) while 14 images install micropipenv unnecessarily. Issue #1685 was created with comprehensive problem description covering ~238MB total waste across unused installations, detailed scope analysis, multiple solution options, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-21T15:06:04.114Z
Learning: jiridanek requested GitHub issue creation for multi-platform dependency locking investigation during PR #1396 review. Issue #1423 was successfully created with comprehensive problem description covering ARM64 wheel availability but being ignored due to AMD64-only dependency locking, root cause analysis of platform-specific pipenv limitations, immediate conditional installation solution, multi-platform locking ecosystem analysis, broader affected areas investigation, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: jiridanek prefers to implement systematic cleanup improvements through dedicated GitHub issues (like #2076) rather than applying individual point fixes during PR reviews, maintaining consistency with their established pattern of comprehensive code quality improvements.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1972
File: runtimes/pytorch+llmcompressor/ubi9-python-3.12/Pipfile:11-14
Timestamp: 2025-08-18T12:32:34.595Z
Learning: In opendatahub-io/notebooks, jiridanek's team uses a sophisticated dependency management workaround where conflicting packages like vllm are placed in [dev-packages] sections of Pipfiles. This allows `pipenv lock` to generate complete dependency resolution during lock file creation, while runtime builds use `micropipenv install` (without --dev) to avoid installing the conflicting dev dependencies. This strategy enables successful Pipfile.lock generation despite package incompatibilities like vllm conflicting with compressed-tensors.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1720
File: jupyter/trustyai/ubi9-python-3.12/requirements.txt:546-572
Timestamp: 2025-08-07T12:37:47.314Z
Learning: In the opendatahub-io/notebooks repository, strict alignment of debugpy versions across all images is not enforced as a policy. Version drift is tolerated and dependency versions are primarily managed by Pipenv locking. Alignment is only considered when inconsistencies are surfaced by tooling or cause issues.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#2114
File: Makefile:22-24
Timestamp: 2025-08-27T07:37:13.713Z
Learning: In the opendatahub-io/notebooks repository, when transitioning from Python 3.11 to 3.12 as the default RELEASE_PYTHON_VERSION, RStudio images (both c9s and rhel9 variants) should retain Python 3.11 support, requiring the piplock-renewal.yaml workflow matrix to include both Python versions ["3.11", "3.12"].

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1760
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:241-244
Timestamp: 2025-08-08T08:38:32.988Z
Learning: Policy: In opendatahub-io/notebooks, do not remove micropipenv from Python 3.11 images to avoid breaking existing users. Cleanups can deduplicate duplicate installs and remove unused uv, but micropipenv must remain present in 3.11 images.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1782
File: manifests/overlays/additional/jupyter-trustyai-cpu-py312-ubi9-imagestream.yaml:1-1
Timestamp: 2025-08-08T14:57:20.636Z
Learning: In opendatahub-io/notebooks, when validating imagestream manifest dependency versions, compare manifest major.minor values against exact pinned versions in requirements.txt/Pipfile.lock for the same image; manifests intentionally omit patch numbers (project convention).