[rhoai-2.25] RHAIENG-5133: bootstrap setuptools before uv pip builds#2428
[rhoai-2.25] RHAIENG-5133: bootstrap setuptools before uv pip builds#2428jiridanek wants to merge 2 commits into
Conversation
Seed setuptools/wheel and extend build_constraints.txt (>=80.9.0,<82) before uv pip install where legacy sdist builds need pkg_resources. CI on rhoai-2.25 push (be05c75): pkg_resources failures in jupyter-trustyai amd64, jupyter-datascience ppc64le, and runtime-datascience s390x only. Update both Dockerfile.cpu (GHA) and Dockerfile.konflux.cpu for those three images. Co-authored-by: Cursor <cursoragent@cursor.com>
|
[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. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
📝 WalkthroughWalkthroughSix Dockerfiles (jupyter/datascience, jupyter/trustyai, runtimes/datascience, each with cpu and konflux.cpu variants) are updated to write build_constraints.txt using printf instead of echo, and to pre-install setuptools>=80.9.0,<82 with wheel before running uv pip install with --build-constraint on ppc64le/s390x builds. ChangesSetuptools build-constraint pre-install across Dockerfiles
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
![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 (1)
jupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpu (1)
37-40: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove the empty continuation line — deprecated by BuildKit.
Line 38 is blank right after a
\-continued line. Docker'sNoEmptyContinuationbuild check flags this as deprecated, noting support "will be removed... entirely, causing builds to break."🧹 Proposed fix
printf '%s\n' 'setuptools>=80.9.0,<82' 'wheel' > build_constraints.txt && \ - # we often don't know the correct hashes and `--require-hashes` would therefore fail on non amd64, where building is common. UV_LINK_MODE=copy uv pip install --strict --no-deps --refresh --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml --build-constraint build_constraints.txt🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@jupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpu` around lines 37 - 40, The Dockerfile.konflux.cpu build step has an empty continuation line after a backslash-terminated command, which triggers BuildKit’s NoEmptyContinuation check. Update the chained RUN-style sequence around the build_constraints.txt write and the following uv pip install command so there is no blank line between continued lines, keeping the existing command flow intact and the continuation formatting valid.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu`:
- Around line 32-39: The bootstrap install in the Dockerfile.cpu RUN block still
allows an unbounded setuptools version before build_constraints.txt exists, so
pin the initial uv/setuptools/wheel install to the same setuptools range used
elsewhere. Update the bootstrap step near the uv pip install flow so the ambient
stage cannot pick up setuptools 82+ and break pkg_resources, keeping the later
build_constraints.txt logic unchanged.
In `@jupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpu`:
- Around line 32-40: Pin the bootstrap setuptools version in the
Dockerfile.konflux.cpu RUN step so it matches the build constraint used later,
and remove the empty continuation line before the final uv pip install to avoid
deprecated BuildKit syntax. Update the bootstrap install near the pip install
command to use the same setuptools range already written into
build_constraints.txt, and keep the RUN chain continuous without a blank line
before UV_LINK_MODE=copy uv pip install.
---
Nitpick comments:
In `@jupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpu`:
- Around line 37-40: The Dockerfile.konflux.cpu build step has an empty
continuation line after a backslash-terminated command, which triggers
BuildKit’s NoEmptyContinuation check. Update the chained RUN-style sequence
around the build_constraints.txt write and the following uv pip install command
so there is no blank line between continued lines, keeping the existing command
flow intact and the continuation formatting valid.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 9a7cc8e6-a803-4ea9-a536-295e0fa3462e
📒 Files selected for processing (6)
jupyter/datascience/ubi9-python-3.12/Dockerfile.cpujupyter/datascience/ubi9-python-3.12/Dockerfile.konflux.cpujupyter/trustyai/ubi9-python-3.12/Dockerfile.cpujupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpuruntimes/datascience/ubi9-python-3.12/Dockerfile.cpuruntimes/datascience/ubi9-python-3.12/Dockerfile.konflux.cpu
| RUN --mount=type=cache,target=/root/.cache/uv \ | ||
| pip install --no-cache uv && \ | ||
| pip install --no-cache uv setuptools wheel && \ | ||
| # the devel script is ppc64le specific - sets up build-time dependencies | ||
| source ./devel_env_setup.sh && \ | ||
| # This may have to download and compile some dependencies, and as we don't lock requirements from `build-system.requires`, | ||
| echo "setuptools<82" > build_constraints.txt && \ | ||
| printf '%s\n' 'setuptools>=80.9.0,<82' 'wheel' > build_constraints.txt && \ | ||
|
|
||
| # we often don't know the correct hashes and `--require-hashes` would therefore fail on non amd64, where building is common. | ||
| UV_LINK_MODE=copy uv pip install --strict --no-deps --refresh --no-config --no-progress --verify-hashes --compile-bytecode --index-strategy=unsafe-best-match --requirements=./pylock.toml --build-constraint build_constraints.txt |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the target Dockerfile with line numbers.
sed -n '1,120p' jupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpu | cat -n
# Find nearby references to the same bootstrap pattern and any bounded setuptools usage.
rg -n "setuptools>=80\.9\.0,<82|pip install --no-cache uv setuptools wheel|NoEmptyContinuation|empty continuation" jupyter/trustyai -S
# Show the exact Dockerfile line span with visible blank lines.
nl -ba jupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpu | sed -n '28,44p'Repository: red-hat-data-services/notebooks
Length of output: 6105
🌐 Web query:
Docker BuildKit "NoEmptyContinuation" empty continuation lines deprecated future releases remove support docs
💡 Result:
The "NoEmptyContinuation" build check in Docker BuildKit identifies instances where empty lines follow a newline escape character () in a Dockerfile [1][2][3]. Key details regarding this deprecation: - Status: The use of empty continuation lines is officially deprecated [1][4]. Future versions of the Dockerfile syntax will treat these as errors, which will cause builds to fail [1][2]. - Reason: Empty continuation lines create ambiguity and confusion regarding where an instruction ends, potentially leading to errors in how Docker interprets the build steps [5]. - How to fix: To ensure compatibility with future releases, you should remove any blank lines that occur between lines ending with a backslash [1][4][3]. - Valid Alternatives: If you need to include spacing or documentation within a multi-line instruction, you can use comment lines instead of empty lines [1][6]. Docker interprets lines starting with # as comments, and they are not considered empty for the purposes of this check [1][7]. Example of the fix: Bad: FROM alpine RUN apk add \ gnupg \ curl Good (using a comment): FROM alpine RUN apk add \ # Install dependencies gnupg \ curl You can also simply remove the blank lines entirely to keep the instruction contiguous [1][4][3]. BuildKit includes this as part of its build checks to help developers proactively clean up their Dockerfiles [2][3].
Citations:
- 1: https://docs.docker.com/reference/build-checks/no-empty-continuation/
- 2: https://docs.docker.com/reference/build-checks/
- 3: https://www.erroratlas.net/errors/docker-build-check-no-empty-continuation
- 4: https://tally.wharflab.com/rules/buildkit/NoEmptyContinuation
- 5: Warn/deprecate continuing on empty lines in
Dockerfilemoby/moby#29161 - 6: https://docker.ubitools.com/reference/build-checks/no-empty-continuation/
- 7: https://stackoverflow.com/questions/46708053/empty-continuation-lines-will-become-errors-how-should-i-comment-my-dockerfil
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the same block in the sibling Dockerfile for comparison.
sed -n '28,42p' jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu | cat -n
# Look for setuptools constraints and pkg_resources-related build issues in this subtree.
rg -n "setuptools>=80\.9\.0,<82|pkg_resources|ModuleNotFoundError|build_constraints.txt|pip install --no-cache uv setuptools wheel" jupyter/trustyai -S
# Show any Dockerfile build-check comments around empty continuation usage.
rg -n "empty continuation|NoEmptyContinuation|continuation" jupyter/trustyai -SRepository: red-hat-data-services/notebooks
Length of output: 2259
🌐 Web query:
setuptools 82 pkg_resources removed release notes
💡 Result:
In setuptools version 82.0.0, the pkg_resources module was officially removed [1][2]. The release notes state that pkg_resources is no longer maintained, is no longer used internally by setuptools, and is not included in distributions or installations of version 82.0.0 and later [3][4]. Projects and environments that still rely on pkg_resources for functionality such as namespace packages are advised to depend on older versions of setuptools [1][2][5]. The setuptools documentation recommends the following replacements for users migrating away from pkg_resources [3][4]: * Resource access: Use importlib.resources (or the importlib_resources backport) [3][4]. * Distribution metadata and entry points: Use importlib.metadata (or the importlib_metadata backport) [3][4]. * Requirement and version parsing: Use the packaging library (specifically packaging.requirements.Requirement and packaging.markers.Marker) [4]. The removal of pkg_resources was part of a long-term deprecation process that began as early as version 67.5.0 [3]. Development work to finalize this removal was tracked in issue #3085 and completed in pull request #5007 [1][5].
Citations:
- 1: https://setuptools.pypa.io/en/stable/history.html
- 2: https://github.com/pypa/setuptools/blob/v82.0.0/NEWS.rst
- 3: https://setuptools.pypa.io/en/latest/deprecated/pkg_resources.html
- 4: https://github.com/pypa/setuptools/blob/main/docs/deprecated/pkg_resources.rst
- 5: Remove pkg_resources pypa/setuptools#5007
🌐 Web query:
setuptools 80.9.0 pkg_resources ModuleNotFoundError build issue
💡 Result:
The ModuleNotFoundError: No module named 'pkg_resources' error occurs because the pkg_resources module was officially removed from setuptools in version 82.0.0, released in February 2026 [1][2][3]. Although setuptools versions prior to 82.0.0 (such as 80.9.0) began issuing deprecation warnings, they still included the module [4][5]. If you are encountering this error, your environment is likely installing setuptools 82.0.0 or later as a build dependency [6][7]. To resolve this issue, you have three primary options: 1. Pin setuptools to an older version (Recommended for existing projects): If you cannot immediately update your code to remove dependencies on pkg_resources, pin your environment to a version of setuptools that still contains the module, such as setuptools<82.0.0 [1][7][8]. For example, add the following to your requirements.txt or constraint file: setuptools<82.0.0 2. Use a backport (If you cannot downgrade): If you absolutely require pkg_resources at runtime but cannot downgrade setuptools, you can install the pkg-resources-backport package [9]. Note that this is a temporary compatibility solution [9]. 3. Migrate your code (Long-term solution): The official recommendation from the PyPA is to migrate away from pkg_resources, which has been deprecated due to performance and architectural limitations [10]. Replace its usage with standard library alternatives: - Resource Access: Use importlib.resources (or the importlib_resources backport for older Python versions) [10][3]. - Distribution Metadata & Entry Points: Use importlib.metadata (or the importlib_metadata backport) [10][3]. - Versioning and Requirements: Use the packaging library [10]. For build environments specifically, ensure that your pyproject.toml or build configuration pins setuptools to a compatible version if the project's build system relies on pkg_resources [6][7].
Citations:
- 1: https://stackoverflow.com/questions/7446187/no-module-named-pkg-resources
- 2: Remove pkg_resources pypa/setuptools#5007
- 3: https://github.com/pypa/setuptools/blob/v82.0.0/NEWS.rst
- 4: https://bugzilla.redhat.com/show_bug.cgi/show_bug.cgi?id=2403565
- 5: Need to futureproof model_zoo.py against setuptools breaking change announced for 2025-12 facebookresearch/detectron2#5494
- 6: [BUG] Restore
pkg_resourcespypa/setuptools#5174 - 7: Build fails with setuptools 81+ due to pkg_resources removal openai/CLIP#528
- 8: CKAN broken with latest setuptools version (setuptools>=82) ckan/ckan#9246
- 9: https://pypi.org/project/pkg-resources-backport/
- 10: https://setuptools.pypa.io/en/latest/deprecated/pkg_resources.html
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
paths = [
Path("jupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpu"),
Path("jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu"),
]
for p in paths:
print(f"\n== {p} ==")
for i, line in enumerate(p.read_text().splitlines(), 1):
if 30 <= i <= 41:
print(f"{i:>4}: {line}")
PY
rg -n "setuptools<82|setuptools>=80\.9\.0,<82|pkg_resources" jupyter/trustyai/ubi9-python-3.12 -SRepository: red-hat-data-services/notebooks
Length of output: 2397
Pin the bootstrap setuptools and remove the empty continuation line.
pip install --no-cache uv setuptools wheelcan still pullsetuptools82+, while the laterbuild_constraints.txtonly constrains the build step; align the bootstrap install here too.- Drop the blank line before the final
uv pip install; BuildKit flags empty continuation lines as deprecated and future syntax will reject them.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@jupyter/trustyai/ubi9-python-3.12/Dockerfile.konflux.cpu` around lines 32 -
40, Pin the bootstrap setuptools version in the Dockerfile.konflux.cpu RUN step
so it matches the build constraint used later, and remove the empty continuation
line before the final uv pip install to avoid deprecated BuildKit syntax. Update
the bootstrap install near the pip install command to use the same setuptools
range already written into build_constraints.txt, and keep the RUN chain
continuous without a blank line before UV_LINK_MODE=copy uv pip install.
TrustyAI: declare pandas build deps in [tool.uv.pip] extra-build-dependencies (injected into uv's isolated build env). Copy pyproject.toml into whl-cache, drop --no-config, keep build_constraints setuptools>=80.9.0,<82. Datascience/runtime: CI failures were in pyarrow builder stages, not uv pip side installs — pin setuptools==80.9.0 after requirements-build.txt in Dockerfile.cpu (sync konflux). Revert host-env pip bootstrap before uv pip. Sub-task: https://redhat.atlassian.net/browse/RHAIENG-5986 Co-authored-by: Cursor <cursoragent@cursor.com>
1 participant
Summary
Fix
ModuleNotFoundError: No module named 'pkg_resources'during image builds.Sub-task: RHAIENG-5986 (under RHAIENG-5133).
Part of RHAIENG-5133 remediation — PR-8.
Root cause (per-image)
jupyter-trustyaiuv pip(pandas 1.5.3 sdist)[tool.uv.pip] extra-build-dependencies— injected into isolated build envjupyter-datasciencesetup.py)setuptools==80.9.0afterrequirements-build.txtinDockerfile.cpu(konflux already had it)runtime-datasciencerequirements-build.txtpulled setuptools 82+)CI runs: 28484294179, 28464164759.
Not a host-env problem: uv uses build isolation — side
pip install setuptoolsbeforeuv pipdoes not affect isolated sdist builds. TrustyAI fix uses uv'sextra-build-dependencies; datascience/runtime fixes target the pyarrow builder stages wherepython setup.pyruns outside uv.TrustyAI changes
pyproject.toml:Dockerfile.cpu + Dockerfile.konflux.cpu (whl-cache):
COPY pyproject.tomlalongsidepylock.toml--no-configso uv reads[tool.uv.pip]build_constraints.txt:setuptools>=80.9.0,<82(cap version when setuptools is a build dep)pip install setuptoolsDatascience / runtime-datascience changes
pip install --force-reinstall setuptools==80.9.0 wheelafterrequirements-build.txt(RHAIENG-5986 comment)meson<1.11build-constraint only)Test plan
jupyter-trustyaiamd64 buildjupyter-datascienceppc64le buildruntime-datasciences390x build