RHOAIENG-21842: bump JupyterLab-related dependencies in all Python 3.11 and 3.12 Pipfiles #1218
Conversation
jiridanek
added
do-not-merge/hold
tide/merge-method-squash
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
WalkthroughThis update raises the version of JupyterLab and related packages across multiple Pipfiles and requirements.txt files, and updates corresponding version annotations in several image stream YAML manifests. No package names, dependencies, or code structures were changed—only minor and patch version bumps for Jupyter ecosystem components. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested labels
Suggested reviewers
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
jupyter/datascience/ubi9-python-3.11/Pipfile (1)
34-41: Pinjupyter-serverfor reproducibilityFor the same reasons already mentioned, consider an exact pin here as well:
-jupyter-server = "~=2.16.0" +jupyter-server = "==2.16.0"Ensures image rebuilds remain deterministic across all notebook flavours.
jupyter/tensorflow/ubi9-python-3.11/Pipfile (1)
39-46: Consistency with other imagesAll other updated Pipfiles now pin
jupyterlabexactly but allowjupyter-serverto float. Please decide on one policy (exact pin vs compatible release) and apply it everywhere to avoid divergence between images built at different times.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
jupyter/datascience/ubi9-python-3.11/Pipfile(1 hunks)jupyter/minimal/ubi9-python-3.11/Pipfile(1 hunks)jupyter/pytorch/ubi9-python-3.11/Pipfile(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.11/Pipfile(1 hunks)jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile(1 hunks)jupyter/tensorflow/ubi9-python-3.11/Pipfile(1 hunks)jupyter/trustyai/ubi9-python-3.11/Pipfile(1 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-20T11:51:59.716Z
Learning: This project follows the practice of associating PRs with Jira tickets from https://issues.redhat.com for traceability between requirements, release process, and product documentation. This is critical for enterprise software development compliance and cross-team coordination.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
jupyter/minimal/ubi9-python-3.11/Pipfile (2)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1127
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:20-20
Timestamp: 2025-06-27T07:49:01.198Z
Learning: jiridanek reviewed the transformers v4.50.0 release notes and assessed that the changes are minimal and unlikely to cause TrustyAI integration problems, indicating the actual changelog contained mostly bug fixes and minor additions rather than breaking changes.
jupyter/rocm/pytorch/ubi9-python-3.11/Pipfile (2)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
jupyter/pytorch/ubi9-python-3.11/Pipfile (2)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1127
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:20-20
Timestamp: 2025-06-27T07:49:01.198Z
Learning: jiridanek reviewed the transformers v4.50.0 release notes and assessed that the changes are minimal and unlikely to cause TrustyAI integration problems, indicating the actual changelog contained mostly bug fixes and minor additions rather than breaking changes.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
jupyter/datascience/ubi9-python-3.11/Pipfile (1)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
jupyter/trustyai/ubi9-python-3.11/Pipfile (3)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1127
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:20-20
Timestamp: 2025-06-27T07:49:01.198Z
Learning: jiridanek reviewed the transformers v4.50.0 release notes and assessed that the changes are minimal and unlikely to cause TrustyAI integration problems, indicating the actual changelog contained mostly bug fixes and minor additions rather than breaking changes.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1127
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:20-20
Timestamp: 2025-06-27T07:49:01.198Z
Learning: Transformers v4.50.0 contains only non-breaking changes including documentation redesign, repository maintenance, performance enhancements, and bug fixes, with no API changes that would affect TrustyAI integration.
jupyter/tensorflow/ubi9-python-3.11/Pipfile (2)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1127
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:20-20
Timestamp: 2025-06-27T07:49:01.198Z
Learning: jiridanek reviewed the transformers v4.50.0 release notes and assessed that the changes are minimal and unlikely to cause TrustyAI integration problems, indicating the actual changelog contained mostly bug fixes and minor additions rather than breaking changes.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile (2)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Generate list of images for release notes
🔇 Additional comments (3)
jupyter/trustyai/ubi9-python-3.11/Pipfile (1)
45-56: Double-check Elyra ↔ JupyterLab compatibility
odh-elyrais still at4.2.1whilejupyterlabjumped to4.4.4.
Upstream Elyra 4.2.x was released against the 4.2 JupyterLab line; it hasn’t been officially tested on 4.4.x yet. Runtime UI extensions may silently fail to load.Before merging, open one of the TrustyAI images, launch JupyterLab and confirm that:
- The Elyra panel appears with no JS console errors.
- Elyra pipelines can be created & saved.
If issues appear, bump Elyra to ≥ 4.4 or keep JupyterLab at 4.2.* for this image.
jupyter/pytorch/ubi9-python-3.11/Pipfile (1)
44-51: ✅ All Pipfiles now pin JupyterLab 4.4.x – verify front-end plugin compatibilityRan:
rg -n --no-heading 'jupyterlab\s*=\s*"==4\.[0-3]\.' || echo "✅ All Pipfiles aligned on 4.4.x"Output: ✅ All Pipfiles aligned on 4.4.x
Next steps:
- Confirm any prebuilt extensions (e.g.
odh-elyra==4.2.1) declare"engines": { "jupyterlab": ">=4.4.0" }in their package.json, so they load under 4.4.4.- Verify upstream peerDependency ranges for
jupyterlab-gitandjupyterlab-lspcover 4.4.x to avoid silent breakage.jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile (1)
41-49: Keep an eye onjupyter-resource-usage& Lab 4.4 integrationGood to see the coordinated bump (
jupyterlab4.4.4,jupyterlab-lsp5.1.1,jupyter-resource-usage1.1.1).
jupyter-resource-usagebundles a server extension that imports internal JupyterLab utilities; mismatched versions previously caused 500s on notebook start-up.No requested changes — just flagging it for post-build smoke-testing (open a notebook, check the resource meter loads).
Tagging for visibility.
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (12)
jupyter/datascience/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/minimal/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/rocm/pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/trustyai/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/datascience/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/rocm-pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/rocm-tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lock
📒 Files selected for processing (12)
jupyter/datascience/ubi9-python-3.11/requirements.txt(3 hunks)jupyter/minimal/ubi9-python-3.11/requirements.txt(3 hunks)jupyter/pytorch/ubi9-python-3.11/requirements.txt(3 hunks)jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt(3 hunks)jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txt(3 hunks)jupyter/tensorflow/ubi9-python-3.11/requirements.txt(3 hunks)jupyter/trustyai/ubi9-python-3.11/requirements.txt(3 hunks)runtimes/datascience/ubi9-python-3.11/requirements.txt(1 hunks)runtimes/pytorch/ubi9-python-3.11/requirements.txt(1 hunks)runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt(1 hunks)runtimes/rocm-tensorflow/ubi9-python-3.11/requirements.txt(1 hunks)runtimes/tensorflow/ubi9-python-3.11/requirements.txt(1 hunks)
✅ Files skipped from review due to trivial changes (6)
- runtimes/rocm-tensorflow/ubi9-python-3.11/requirements.txt
- jupyter/datascience/ubi9-python-3.11/requirements.txt
- jupyter/tensorflow/ubi9-python-3.11/requirements.txt
- runtimes/tensorflow/ubi9-python-3.11/requirements.txt
- runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt
- jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txt
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-20T11:51:59.716Z
Learning: This project follows the practice of associating PRs with Jira tickets from https://issues.redhat.com for traceability between requirements, release process, and product documentation. This is critical for enterprise software development compliance and cross-team coordination.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.869Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
runtimes/datascience/ubi9-python-3.11/requirements.txt (2)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
</retrieved_learning>
runtimes/pytorch/ubi9-python-3.11/requirements.txt (1)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
jupyter/minimal/ubi9-python-3.11/requirements.txt (7)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.869Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
jupyter/pytorch/ubi9-python-3.11/requirements.txt (7)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.869Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core jupyterlab package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
</retrieved_learning>
jupyter/trustyai/ubi9-python-3.11/requirements.txt (7)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.869Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core jupyterlab package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
</retrieved_learning>
jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt (8)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.149Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.406Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.869Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core jupyterlab package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
</retrieved_learning>
⏰ Context from checks skipped due to timeout of 90000ms (14)
- GitHub Check: build (jupyter-minimal-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (cuda-jupyter-tensorflow-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-runtime-tensorflow-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (runtime-cuda-tensorflow-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-runtime-pytorch-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-jupyter-tensorflow-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (jupyter-trustyai-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (cuda-jupyter-pytorch-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (cuda-jupyter-minimal-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (jupyter-datascience-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-jupyter-minimal-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-jupyter-pytorch-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (runtime-datascience-ubi9-python-3.11, linux/amd64, false) / build
- GitHub Check: build (runtime-cuda-pytorch-ubi9-python-3.11, linux/amd64, false) / build
🔇 Additional comments (10)
jupyter/trustyai/ubi9-python-3.11/requirements.txt (2)
1014-1016: Jupyter-Server bump looks good – double-check cross-image alignment
jupyter-server==2.16.0is still within the 2.x stream used across the repo and keeps API compatibility with JupyterLab ≥4.2. No functional concerns here.
Please just verify the other notebook images in the PR consume the same server version so we don’t end up with a mixed fleet.
1026-1028: JupyterLab 4.4.4 upgrade – watch extension compatibilityThe jump to 4.4.4 is safe for core usage and matches the pinning strategy (exact
==).
Upstream extensions (jupyterlab-lsp, Elyra, custom widgets, etc.) must all be tested against 4.4.x. From the lockfile they look current, but please run the smoke/UI tests before releasing.runtimes/pytorch/ubi9-python-3.11/requirements.txt (1)
1052-1150: All images consistently pin multidict==6.5.1 with no known vulnerabilities
rgcheck confirms every notebook and runtime requirements file now uniformly usesmultidict==6.5.1—no version skew.- GitHub Advisory Database query returned no security vulnerabilities for any
multidictversion, including 6.5.1.No further action required.
runtimes/datascience/ubi9-python-3.11/requirements.txt (1)
1042-1139: multidict pin consistency verified – no vulnerabilities detected
- Every Jupyter and runtime image is already pinned to
multidict==6.5.1pip-auditreports no known CVEs for version 6.5.1No further action needed.
jupyter/pytorch/ubi9-python-3.11/requirements.txt (3)
987-989:jupyterlabjump to 4.4.x looks fine – just make sure 3rd-party lab extensions still load.
jupyterlab 4.4.4raises the minimum Python to 3.9 (our base image is 3.11 – OK) and tightens the peer-dep tojupyter-server>=2.8.1,<3.
Nothing actionable here, just flagging that smoke-testing the notebook UI (opening, saving, running a simple cell) after the build is a must.
975-977: Consistent jupyter-server==2.16.0 across all imagesAll occurrences of the
jupyter-serverpin have been updated to2.16.0; no image is on an older version. You can now proceed with your downstream extension or UI smoke tests to catch any silent API breaks.Files and lines checked:
- jupyter/datascience/ubi9-python-3.11/requirements.txt:971
- jupyter/minimal/ubi9-python-3.11/requirements.txt:526
- jupyter/pytorch/ubi9-python-3.11/requirements.txt:975
- jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt:975
- jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txt:993
- jupyter/tensorflow/ubi9-python-3.11/requirements.txt:990
- jupyter/trustyai/ubi9-python-3.11/requirements.txt:1014
1290-1388: Verify CVE-2024-27305 fix in multidict
The PyPA advisory-db lookup didn’t surface any entry for CVE-2024-27305. Please confirm the patched version by checking:
- multidict’s upstream CHANGELOG or GitHub Security Advisories for CVE-2024-27305
- the first release that includes the fix (e.g. 6.6.0)
If the fix indeed landed in 6.6.0 (or later), revert to
multidict==6.6.0and address the original dependency conflict another way (for example, upper-pinaiohttp<3.13). Let me know if you need help crafting a safe pin set.jupyter/minimal/ubi9-python-3.11/requirements.txt (2)
526-528: No conflictingjupyter-serverpins detectedI ran a repo-wide search for any
jupyter-serverconstraints other than==2.16.0and found none. All requirements and Pipfiles are already aligned with the new pin—no further changes needed.
538-540: Verify JupyterLab 4.4.x Front-end Extension CompatibilitySince this repo doesn’t include any package.json files to programmatically confirm extension pins, please manually smoke-test the Lab upgrade:
• Open JupyterLab and confirm the Trash icon/UI appears
• Load and exercise your primary server-side extensions (Git, LSP, Elyra) and ensure they initialize without frontend errorsjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt (1)
975-977: No jupyter-server-proxy dependency detected — merge OKA search of
jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtfound nojupyter-server-proxyentry. Since this image doesn’t include the proxy extension, bumping tojupyter-server==2.16.0poses no downstream proxy compatibility risk.
…11 / 3.12 Pipfiles - fixup: align `jupyter-bokeh` version to `~3.0.5` for TrustyAI 0.6.1 compatibility This update pulls in the Trash updates in JupyterLab UI
jiridanek
force-pushed
the
jd_jupyterlab_444
branch
from
6b57a34 to
a4a5bbb
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
manifests/base/jupyter-tensorflow-notebook-imagestream.yaml (1)
28-34: Bump Odh-Elyra to 4.4 to align with JupyterLab 4.4
JupyterLab was updated from 4.2→4.4 (2025.1 tag) but Odh-Elyra remains pinned at 4.2 across multiple images. Upstream Elyra 4.2 only supports JL 4.2; JL 4.4 support landed in Elyra 4.4, so please update Odh-Elyra to a 4.4.x release to avoid extension-loader warnings at startup.Please update these occurrences (and any others) to Odh-Elyra 4.4:
• manifests/overlays/additional/jupyter-trustyai-cpu-py312-ubi9-imagestream.yaml:40
• manifests/base/jupyter-rocm-pytorch-notebook-imagestream.yaml:38,76
• manifests/base/jupyter-pytorch-notebook-imagestream.yaml:41,82
• manifests/overlays/additional/jupyter-tensorflow-cuda-py312-ubi9-imagestream.yaml:41
• manifests/overlays/additional/jupyter-pytorch-cuda-py312-ubi9-imagestream.yaml:40
• manifests/base/jupyter-tensorflow-notebook-imagestream.yaml:42,83
• manifests/base/jupyter-datascience-notebook-imagestream.yaml:36,73
• manifests/overlays/additional/jupyter-pytorch-rocm-py312-ubi9-imagestream.yaml:37
• manifests/base/jupyter-rocm-tensorflow-notebook-imagestream.yaml:38,75
• manifests/base/jupyter-trustyai-notebook-imagestream.yaml:41,83
• manifests/overlays/additional/jupyter-datascience-cpu-py312-ubi9-imagestream.yaml:35…and in all Pipfile entries currently pegged at 4.2.3 under jupyter//Pipfile:
• e.g. jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile:39
• jupyter/pytorch/ubi9-python-3.12/Pipfile:42
• jupyter/trustyai//Pipfile:46
(etc. – see full search output)
🧹 Nitpick comments (1)
jupyter/pytorch+llmcompressor/ubi9-python-3.11/requirements.txt (1)
986-988: JupyterLab bumped to 4.4.4 (Python >= 3.9) — LGTM; add basic UI smoke tests for TrashPin looks correct and matches the PR goal (Trash improvements). Recommend adding simple validation steps to unblock the PR hold:
- Launch the py311 image.
- Create a file, delete it, verify it appears under “Trash.”
- Restore the file, verify it returns to its original path.
- Empty Trash and verify directory is cleaned without errors.
I can help draft these as scripted steps for your test guide if useful.
| jupyterlab==4.4.4; python_version >= '3.9' \ | ||
| --hash=sha256:163fee1ef702e0a057f75d2eed3ed1da8a986d59eb002cbeb6f0c2779e6cd153 \ | ||
| --hash=sha256:711611e4f59851152eb93316c3547c3ec6291f16bb455f1f4fa380d25637e0dd |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Double-check extension compatibility after moving to jupyterlab 4.4.4
Jumping two minor releases is usually safe, but a few ecosystem packages sometimes lag (e.g. jupyter-lab-lsp, widgets). Recommend a quick scan for hard upper bounds in the repo to avoid runtime surprises.
🏁 Script executed:
#!/bin/bash
# Detect packages that cap JupyterLab below 4.4
rg --no-heading --line-number -e 'jupyterlab[ <>=~]*[0-9]+\.[0-9]+\.[0-9]+' |
grep -v '4\.4\.4' || echo "No pinned older versions found."Length of output: 160
Address hard‐pinned JupyterLab version in example
Our scan uncovered a conflicting pin at examples/jupyterlab-with-elyra/Dockerfile:48:
- examples/jupyterlab-with-elyra/Dockerfile:48
Please update this to align with jupyterlab==4.4.4 (e.g.
jupyterlab==4.2.7
jupyterlab==4.4.4orjupyterlab>=4.4.4) to avoid version conflicts in your example.
🤖 Prompt for AI Agents
In jupyter/datascience/ubi9-python-3.11/requirements.txt around lines 1003 to
1005, the JupyterLab version is hard-pinned to 4.4.4, but the example Dockerfile
at examples/jupyterlab-with-elyra/Dockerfile line 48 uses version 4.2.7, causing
a version conflict. Update the Dockerfile line 48 to match this file by changing
the JupyterLab version to 4.4.4 or a compatible range like >=4.4.4 to ensure
consistency and avoid conflicts.
| jupyterlab==4.4.4; python_version >= '3.9' \ | ||
| --hash=sha256:163fee1ef702e0a057f75d2eed3ed1da8a986d59eb002cbeb6f0c2779e6cd153 \ | ||
| --hash=sha256:711611e4f59851152eb93316c3547c3ec6291f16bb455f1f4fa380d25637e0dd |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
jupyterlab 4.4.4 bump: good; ensure extension compatibility and validate Trash UI
- Python constraint raised to >=3.9 matches upstream; OK for py311 images.
- Pinned extensions around it look compatible at a glance (e.g., jupyterlab-server==2.27.3, jupyterlab-git==0.51.2, jupyterlab-lsp==5.1.1). Please validate in CI/manual tests that these extensions load under 4.4.4.
- Given the PR objective (Trash feature), include a short manual check in testing notes (e.g., delete file -> appears in Trash, restore/remove actions, “Empty Trash” behavior).
Script to sanity-check repository-wide alignment on JupyterLab:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Verify jupyterlab==4.4.4 across requirements.txt and Pipfiles"
fd -t f -a requirements.txt Pipfile | while read -r f; do
if rg -n "jupyterlab\s*==\s*4\.4\.4" "$f" > /dev/null; then
printf "OK %s\n" "$f"
else
printf "MISS %s\n" "$f"
fi
done | sort
echo
echo "Locate any jupyterlab references with mismatched versions:"
rg -n "jupyterlab\s*=="Length of output: 304
To accurately verify the JupyterLab version pinning across both requirements and Pipfile manifests, let’s re-run with a find+grep approach:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Scanning for jupyterlab==4.4.4 in requirements.txt and Pipfile"
find . -type f \( -name 'requirements.txt' -o -name 'Pipfile' \) -print0 \
| xargs -0 grep -Hn "jupyterlab\s*==\s*4\.4\.4" || true
echo
echo "All occurrences of jupyterlab pins:"
grep -RIn "jupyterlab\s*==" .Length of output: 3407
jupyterlab 4.4.4 bump: consistency check & example mismatch
- All notebook image requirements.txt files now consistently pin
jupyterlab==4.4.4 (python_version ≥ 3.9). - One outlier remains in an example:
• examples/jupyterlab-with-elyra/Dockerfile:48 is still pinned to jupyterlab==4.2.7.
Please update this to 4.4.4 or confirm it must stay at 4.2.7 for elyra compatibility. - As before, ensure your CI/manual smoke tests load all extensions under 4.4.4 (e.g., jupyterlab-server, jupyterlab-git, jupyterlab-lsp).
- Add a brief manual verification step for the Trash UI in your testing notes:
• delete → appears in Trash
• restore/remove actions
• “Empty Trash” behavior
🤖 Prompt for AI Agents
In jupyter/tensorflow/ubi9-python-3.11/requirements.txt around lines 1046 to
1048, update the example file examples/jupyterlab-with-elyra/Dockerfile at line
48 to pin jupyterlab to version 4.4.4 instead of 4.2.7 to maintain consistency.
After updating, run CI or manual smoke tests to verify all extensions like
jupyterlab-server, jupyterlab-git, and jupyterlab-lsp load correctly under
version 4.4.4. Also, add a manual verification step in your testing notes to
check the Trash UI functionality including delete, restore/remove actions, and
the “Empty Trash” behavior.
|
@jiridanek: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/kfbuild odh-workbench-jupyter-minimal-cpu-py312-ubi9-on-pull-request |
|
/kfbuild odh-workbench-jupyter-pytorch-cuda-py312-ubi9-on-pull-request |
https://issues.redhat.com/browse/RHOAIENG-21842
Description
This change pulls in the Trash updates in JupyterLab UI
delete_to_trashisTruejupyterlab/jupyterlab#17359Pipfile.lock action
How Has This Been Tested?
Merge criteria:
Summary by CodeRabbit
Summary by CodeRabbit