[Feature] Test Python 3.14#840
Conversation
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughWidened Python compatibility and CI/test targets: pyproject metadata updated to allow Python <3.15 and add 3.14 classifier; CI workflow matrix and setup updated from 3.13→3.14; interactive serial backend function renamed from main to evaluate_cmd with test suite updated accordingly. ChangesPython 3.14 Support Expansion
Interactive Serial Backend Function Rename
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #840 +/- ##
=======================================
Coverage 94.24% 94.24%
=======================================
Files 39 39
Lines 2119 2119
=======================================
Hits 1997 1997
Misses 122 122 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
|
|
|
@liamhuber Somehow the integration tests fail with Python 3.14. It seems to be related to the use of def dynamic_foo():
"""
A decorator for dynamically modifying the Foo class to test
CloudpickleProcessPoolExecutor.
Overrides the `fnc` input of `Foo` with the decorated function.
"""
def as_dynamic_foo(fnc: Callable):
return type(
"DynamicFoo",
(Foo,), # Define parentage
{"__init__": partialmethod(Foo.__init__, fnc)},
)
return as_dynamic_fooI was wondering if you had similar issues with |
|
It seems to be a |
|
I haven't tested 3.14 for workflow yet, so I'm not sure. I've done it only(?) for snippets, but that is pretty trivial. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/pipeline.yml (2)
192-221:unittest_flux_mpichandunittest_flux_openmpiintentionally left on 3.13.Keeping flux-related jobs on 3.13 appears to be a deliberate decision (likely due to
flux-core=0.81.0and related conda packages not being available for Python 3.14). Worth adding a comment in the YAML to document why these differ from the other test jobs, to avoid confusion during future version bumps.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/pipeline.yml around lines 192 - 221, Add an inline comment above the unittest_flux_mpich and unittest_flux_openmpi job definitions explaining why they pin python-version: '3.13' (e.g., flux-core=0.81.0 and related conda packages are not available on Python 3.14), so future maintainers know the version divergence is intentional; place the comment near the job headers (unittest_flux_mpich / unittest_flux_openmpi) and mention the dependency (flux-core=0.81.0) and that the pin is to satisfy conda package compatibility.
44-58:mypyjob still on Python 3.13 — consider whether 3.14 should be added here too.The
mypyjob at Line 51 is the only type-checking job; it still runs on 3.13. While not blocking, any type-checking against 3.14-only syntax or stub differences won't be caught. If this is intentional (no 3.14-specific type changes expected), no action needed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/pipeline.yml around lines 44 - 58, Update the mypy job to also run under Python 3.14 so type-checking covers 3.14-specific syntax/stubs: modify the mypy job (the job named "mypy" and its "Setup Python" step that uses actions/setup-python@v5 and the python-version input) to either use a matrix over python-version including "3.13" and "3.14", or add a parallel mypy job configured with python-version: "3.14"; ensure the subsequent steps (Checkout, Install mypy, Test) run for both Python versions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@tests/integration/test_pyiron_workflow.py`:
- Around line 59-62: The skip condition incorrectly uses sys.version_info.minor
twice; change the decorator's condition to compare the version tuple instead of
comparing .minor fields (e.g., replace the current sys.version_info.minor >= 14
and sys.version_info.minor >= 3 with a tuple comparison like sys.version_info >=
(3, 14) or an equivalent major/minor check) so the `@unittest.skipIf` using
sys.version_info correctly skips on Python versions >= 3.14; update the
`@unittest.skipIf` expression that references sys.version_info in the
test_pyiron_workflow.py decorator accordingly.
---
Nitpick comments:
In @.github/workflows/pipeline.yml:
- Around line 192-221: Add an inline comment above the unittest_flux_mpich and
unittest_flux_openmpi job definitions explaining why they pin python-version:
'3.13' (e.g., flux-core=0.81.0 and related conda packages are not available on
Python 3.14), so future maintainers know the version divergence is intentional;
place the comment near the job headers (unittest_flux_mpich /
unittest_flux_openmpi) and mention the dependency (flux-core=0.81.0) and that
the pin is to satisfy conda package compatibility.
- Around line 44-58: Update the mypy job to also run under Python 3.14 so
type-checking covers 3.14-specific syntax/stubs: modify the mypy job (the job
named "mypy" and its "Setup Python" step that uses actions/setup-python@v5 and
the python-version input) to either use a matrix over python-version including
"3.13" and "3.14", or add a parallel mypy job configured with python-version:
"3.14"; ensure the subsequent steps (Checkout, Install mypy, Test) run for both
Python versions.
| @unittest.skipIf( | ||
| sys.version_info.minor >= 14 and sys.version_info.minor >= 3, | ||
| "Test environment has to be Python <3.14 for dynamic objects.", | ||
| ) |
There was a problem hiding this comment.
Bug in skipIf condition: .minor used twice instead of .major + .minor.
sys.version_info.minor >= 14 and sys.version_info.minor >= 3Both sides reference .minor. The second clause (minor >= 3) is always True when the first (minor >= 14) is, making the and entirely redundant. The condition collapses to sys.version_info.minor >= 14, which happens to work for current Python 3.x releases but would silently misbehave on a future Python 4.x (e.g., 4.0 has minor=0, so no skip even if the same cloudpickle bug persists).
The idiomatic and correct form is a tuple comparison:
🐛 Proposed fix
`@unittest.skipIf`(
- sys.version_info.minor >= 14 and sys.version_info.minor >= 3,
+ sys.version_info >= (3, 14),
"Test environment has to be Python <3.14 for dynamic objects.",
)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tests/integration/test_pyiron_workflow.py` around lines 59 - 62, The skip
condition incorrectly uses sys.version_info.minor twice; change the decorator's
condition to compare the version tuple instead of comparing .minor fields (e.g.,
replace the current sys.version_info.minor >= 14 and sys.version_info.minor >= 3
with a tuple comparison like sys.version_info >= (3, 14) or an equivalent
major/minor check) so the `@unittest.skipIf` using sys.version_info correctly
skips on Python versions >= 3.14; update the `@unittest.skipIf` expression that
references sys.version_info in the test_pyiron_workflow.py decorator
accordingly.
|
|
The minimal tests are using a different Python version: versus: |
|
More issues with threading without global interpreter lock: |
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/unit/backend/test_interactive_serial.py (1)
51-58:⚠️ Potential issue | 🟠 Major | ⚡ Quick winTests should join spawned threads before teardown
Across these test blocks (e.g., Line 51/64/79 and submit-thread flows around Line 97/110), threads are started but never joined. This can leave work in-flight during socket/context teardown and create flaky behavior under Python 3.14 builds.
Add
t.join(timeout=...)(and optionally assertnot t.is_alive()) before closing sockets/contexts in each test.Also applies to: 64-73, 79-89, 97-102, 110-117
🤖 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 `@tests/unit/backend/test_interactive_serial.py` around lines 51 - 58, Threads are started using Thread(target=evaluate_cmd, ...) and t.start() but never joined before socket and context teardown, which can cause flaky behavior. Add t.join(timeout=...) calls (with an optional assertion that not t.is_alive()) immediately before socket.close() and context.term() in all affected test methods. This needs to be fixed at the following locations in test_interactive_serial.py: lines 51-58 (add join before socket.close()), lines 64-73 (add join before socket.close()), lines 79-89 (add join before socket.close()), lines 97-102 (add join before socket.close() in the submit-thread flow), and lines 110-117 (add join before socket.close() in the submit-thread flow). Each location follows the same pattern where evaluate_cmd or a similar thread target is started and then later the socket is closed.
🤖 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 @.github/workflows/pipeline.yml:
- Around line 109-110: The `uv_check` job uses tag-based action references which
pose security risks. Pin both the `actions/checkout@v4` action to its full
commit SHA and the `astral-sh/setup-uv@v7` action to its full commit SHA for
supply-chain hardening. Additionally, add the `persist-credentials: false`
parameter to the checkout action since this job only performs read-only
operations and does not need credential persistence.
- Around line 105-115: In the uv_check job workflow, the pip check command is
running in the runner's default Python environment instead of the uv-managed
virtual environment. Replace the direct `pip check` call with `uv run pip check`
to execute it within the uv-managed environment. Additionally, add a step to
explicitly specify and set up Python 3.14 before the uv setup to align with the
PR objective, using the appropriate GitHub Actions setup-python action.
In `@src/executorlib/backend/interactive_serial.py`:
- Line 15: The public function main() has been renamed to evaluate_cmd() without
providing backward compatibility, which will break external code importing
executorlib.backend.interactive_serial.main. After the evaluate_cmd() function
definition, add a backward-compatible alias or wrapper function named main that
calls evaluate_cmd() with the same arguments to maintain compatibility for at
least one deprecation cycle.
---
Outside diff comments:
In `@tests/unit/backend/test_interactive_serial.py`:
- Around line 51-58: Threads are started using Thread(target=evaluate_cmd, ...)
and t.start() but never joined before socket and context teardown, which can
cause flaky behavior. Add t.join(timeout=...) calls (with an optional assertion
that not t.is_alive()) immediately before socket.close() and context.term() in
all affected test methods. This needs to be fixed at the following locations in
test_interactive_serial.py: lines 51-58 (add join before socket.close()), lines
64-73 (add join before socket.close()), lines 79-89 (add join before
socket.close()), lines 97-102 (add join before socket.close() in the
submit-thread flow), and lines 110-117 (add join before socket.close() in the
submit-thread flow). Each location follows the same pattern where evaluate_cmd
or a similar thread target is started and then later the socket is closed.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: bdf91113-4cee-48f2-8e11-a2b6cd7aa173
📒 Files selected for processing (4)
.github/workflows/pipeline.ymlpyproject.tomlsrc/executorlib/backend/interactive_serial.pytests/unit/backend/test_interactive_serial.py
✅ Files skipped from review due to trivial changes (1)
- pyproject.toml
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/unit/backend/test_interactive_serial.py (1)
51-58:⚠️ Potential issue | 🟠 Major | ⚡ Quick winTests should join spawned threads before teardown
Across these test blocks (e.g., Line 51/64/79 and submit-thread flows around Line 97/110), threads are started but never joined. This can leave work in-flight during socket/context teardown and create flaky behavior under Python 3.14 builds.
Add
t.join(timeout=...)(and optionally assertnot t.is_alive()) before closing sockets/contexts in each test.Also applies to: 64-73, 79-89, 97-102, 110-117
🤖 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 `@tests/unit/backend/test_interactive_serial.py` around lines 51 - 58, Threads are started using Thread(target=evaluate_cmd, ...) and t.start() but never joined before socket and context teardown, which can cause flaky behavior. Add t.join(timeout=...) calls (with an optional assertion that not t.is_alive()) immediately before socket.close() and context.term() in all affected test methods. This needs to be fixed at the following locations in test_interactive_serial.py: lines 51-58 (add join before socket.close()), lines 64-73 (add join before socket.close()), lines 79-89 (add join before socket.close()), lines 97-102 (add join before socket.close() in the submit-thread flow), and lines 110-117 (add join before socket.close() in the submit-thread flow). Each location follows the same pattern where evaluate_cmd or a similar thread target is started and then later the socket is closed.
🤖 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 @.github/workflows/pipeline.yml:
- Around line 109-110: The `uv_check` job uses tag-based action references which
pose security risks. Pin both the `actions/checkout@v4` action to its full
commit SHA and the `astral-sh/setup-uv@v7` action to its full commit SHA for
supply-chain hardening. Additionally, add the `persist-credentials: false`
parameter to the checkout action since this job only performs read-only
operations and does not need credential persistence.
- Around line 105-115: In the uv_check job workflow, the pip check command is
running in the runner's default Python environment instead of the uv-managed
virtual environment. Replace the direct `pip check` call with `uv run pip check`
to execute it within the uv-managed environment. Additionally, add a step to
explicitly specify and set up Python 3.14 before the uv setup to align with the
PR objective, using the appropriate GitHub Actions setup-python action.
In `@src/executorlib/backend/interactive_serial.py`:
- Line 15: The public function main() has been renamed to evaluate_cmd() without
providing backward compatibility, which will break external code importing
executorlib.backend.interactive_serial.main. After the evaluate_cmd() function
definition, add a backward-compatible alias or wrapper function named main that
calls evaluate_cmd() with the same arguments to maintain compatibility for at
least one deprecation cycle.
---
Outside diff comments:
In `@tests/unit/backend/test_interactive_serial.py`:
- Around line 51-58: Threads are started using Thread(target=evaluate_cmd, ...)
and t.start() but never joined before socket and context teardown, which can
cause flaky behavior. Add t.join(timeout=...) calls (with an optional assertion
that not t.is_alive()) immediately before socket.close() and context.term() in
all affected test methods. This needs to be fixed at the following locations in
test_interactive_serial.py: lines 51-58 (add join before socket.close()), lines
64-73 (add join before socket.close()), lines 79-89 (add join before
socket.close()), lines 97-102 (add join before socket.close() in the
submit-thread flow), and lines 110-117 (add join before socket.close() in the
submit-thread flow). Each location follows the same pattern where evaluate_cmd
or a similar thread target is started and then later the socket is closed.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: bdf91113-4cee-48f2-8e11-a2b6cd7aa173
📒 Files selected for processing (4)
.github/workflows/pipeline.ymlpyproject.tomlsrc/executorlib/backend/interactive_serial.pytests/unit/backend/test_interactive_serial.py
✅ Files skipped from review due to trivial changes (1)
- pyproject.toml
🛑 Comments failed to post (3)
.github/workflows/pipeline.yml (2)
105-115:
⚠️ Potential issue | 🟠 Major🧩 Analysis chain
🏁 Script executed:
#!/bin/bash # Verify uv_check currently lacks explicit Python setup and uses plain pip. awk '/^ uv_check:/{flag=1} flag{print} /^ benchmark:/{if(flag) exit}' .github/workflows/pipeline.ymlRepository: pyiron/executorlib
Length of output: 348
🌐 Web query:
uv sync environment activation bash shell how does uv manage virtual environments💡 Result:
uv manages virtual environments by automatically creating, discovering, and synchronizing them, rather than relying on manual shell activation for its internal operations [1][2]. Virtual Environment Management When working on a project, uv creates a virtual environment—by default named.venv—in the project root [1][2]. This environment is created lazily; it is initialized automatically the first time you run a project command such as uv run, uv sync, or uv lock [2][3]. Unlike traditional workflows where you must activate an environment, uv is designed to be "stateless" regarding shell activation [4]. How uv Uses Environments 1. Automatic Discovery: When you run commands like uv run or uv sync, uv walks up the directory tree from your current working directory to discover the project root, the pyproject.toml file, and the associated virtual environment [2][3]. 2. Execution via uv run: The preferred way to interact with your environment is via uv run. This command automatically ensures the environment is synchronized (i.e., dependencies are installed and the lockfile is up to date) before executing your specified command within that isolated environment [2][5]. 3. Manual Syncing: While uv sync happens automatically with other commands, you can manually trigger it to ensure your virtual environment is perfectly aligned with your uv.lock file [5]. 4. Shell Activation: Because uv commands handle environment isolation internally, you do not need to manually run source.venv/bin/activate to use dependencies installed by uv [1][2]. However, if you wish to use your project's dependencies directly in your shell (outside of uv run), you can still activate the environment using standard shell commands (e.g., source.venv/bin/activate) [1][6]. Advanced Configuration and Active Environments By default, uv ignores the VIRTUAL_ENV environment variable during project operations to maintain isolation [7][8]. If you prefer to use an already-active environment rather than uv's managed.venv, you can use the --active flag with commands like uv sync or uv run [9][3]. This flag tells uv to respect the VIRTUAL_ENV environment variable, effectively targeting the currently active shell environment instead of the project-specific one [9][7][8]. You can also explicitly configure the environment path by setting the UV_PROJECT_ENVIRONMENT environment variable [4][8].
Citations:
- 1: https://docs.astral.sh/uv/?featured_on=pythonbytes
- 2: https://docs.astral.sh/uv/guides/projects/
- 3: https://docs.astral.sh/uv/reference/cli/
- 4: astral-sh/uv#14384
- 5: https://docs.astral.sh/uv/concepts/projects/sync/
- 6: https://pypi.org/project/uv/
- 7: astral-sh/uv@989b103
- 8: https://docs.astral.sh/uv/concepts/projects/config/
- 9: astral-sh/uv#17780
🌐 Web query:
uv run command purpose how to run commands in uv virtual environment💡 Result:
The uv run command is the primary method for executing scripts or programs within the context of a uv project or a managed Python environment [1][2][3]. Purpose of uv run The main purpose of uv run is to ensure that commands are executed in a correctly configured, isolated Python environment [1][2]. Its key features include: Automatic Synchronization: When you run a command in a project, uv ensures the virtual environment (typically located in.venv) is up-to-date and consistent with your project's lockfile before execution [1][3][4]. Dependency Management: If a command requires additional packages not already in your project, you can use the --with option to add them to the environment for that specific invocation without permanently modifying your project dependencies [1][4]. Script Execution: It handles Python scripts seamlessly [2]. If you point it to a script file (e.g., uv run script.py), uv runs it with the appropriate interpreter [2][5]. If the script uses inline dependency metadata, uv will automatically create an isolated, ephemeral environment for it [1][2][5]. Flexibility: It works both inside projects (using the project's dependencies) and outside of them (where it may use a discovered virtual environment or a standalone interpreter) [2]. How to Run Commands To run a command using uv, use the following syntax in your terminal: uv run [COMMAND] Examples: Running a Python file: uv run script.py Running a command from the project environment (e.g., a tool or CLI utility): uv run pytest uv run flask run Passing arguments to commands: uv run pytest --verbose Adding temporary dependencies for a single run: uv run --with httpx==0.26.0 python -c "import httpx; print(httpx.version)" Important Usage Notes: Separating Arguments: If you need to separate uv options from the command arguments to avoid ambiguity, use -- [2]: uv run --python 3.12 -- pytest --verbose Alternative to Activation: Unlike traditional workflows that require manually running source.venv/bin/activate (or.venv\Scripts\activate on Windows), uv run makes manual environment activation unnecessary for most tasks, as it handles the environment context automatically [1][3][4]. For running isolated tools without project involvement, consider using uvx (an alias for uv tool run), which is specifically designed to run tools in temporary, isolated environments [6][7].
Citations:
- 1: https://docs.astral.sh/uv/concepts/projects/run/
- 2: https://docs.astral.sh/uv/reference/cli/index.md
- 3: https://astral-sh-uv.mintlify.app/guides/projects
- 4: https://astral-sh-uv.mintlify.app/concepts/projects
- 5: https://docs.astral.sh/uv/guides/scripts/?featured_on=talkpython
- 6: https://docs.astral.sh/uv/concepts/tools/
- 7: https://docs.astral.sh/uv/guides/tools/
🌐 Web query:
GitHub Actions setup-python with uv package manager best practices💡 Result:
The best practice for using the uv package manager in GitHub Actions is to use the official astral-sh/setup-uv action [1][2]. While you can use actions/setup-python to manage Python versions due to its native speed from GitHub-hosted runner caching [1][2], astral-sh/setup-uv provides robust, built-in support for installing uv, managing the uv cache, and configuring environments [1][3][4]. Key best practices include: 1. Use the official action: Employ astral-sh/setup-uv to install and configure uv. Pin the action to a specific commit or full version tag (e.g.,
@v8.1.0) rather than a moving tag to ensure stable builds [1][5]. 2. Enable caching: Set enable-cache: true in your workflow step to persist the uv package store between runs [3][5]. This significantly reduces build times by skipping the re-downloading of dependencies [5]. You can control which files trigger a cache refresh using the cache-dependency-glob input, typically targeting your lockfile (e.g., uv.lock) or requirements files [3]. 3. Manage Python versions: You have two primary options: - astral-sh/setup-uv: Use the python-version input to specify the version [5][4]. This is convenient and keeps configuration within the uv action. - actions/setup-python: Use this action first if you prefer GitHub's native optimization for Python version caching [1][2]. Configure it with python-version-file (pointing to.python-version or pyproject.toml) to automatically pick up the version required by your project [1][2]. 4. Use uv sync: Always use uv sync --locked in CI environments [5]. This command installs dependencies exactly as defined in your uv.lock file and will fail the build if the lockfile is out of sync with your project configuration, ensuring consistency across environments [5]. 5. Execution: Use uv run [command] to execute your tasks (e.g., uv run pytest, uv run ruff check). This ensures that commands are executed within the correct environment managed by uv, without requiring manual activation [5]. Example workflow configuration: name: CI jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - name: Set up Python uses: actions/setup-python@v6 with: python-version-file: "pyproject.toml" - name: Install uv uses: astral-sh/setup-uv@v8.1.0 with: enable-cache: true - name: Sync dependencies run: uv sync --locked --all-extras --dev - name: Run tests run: uv run pytestCitations:
- 1: https://docs.astral.sh/uv/guides/integration/github/
- 2: https://github.com/astral-sh/uv/blob/2b4b5898/docs/guides/integration/github.md
- 3: https://github.com/astral-sh/setup-uv?featured_on=pythonbytes
- 4: https://github.com/astral-sh/setup-uv/blob/main/docs/environment-and-tools.md
- 5: https://pydevtools.com/handbook/tutorial/setting-up-github-actions-with-uv.md
🏁 Script executed:
# Search for other uv usage patterns in the repository workflows rg "uv sync|uv run" .github/workflows/ -A 2 -B 2Repository: pyiron/executorlib
Length of output: 309
🏁 Script executed:
# Check if there are any Python version specifications in the workflow for other jobs rg "python-version|setup-python" .github/workflows/pipeline.yml -B 2 -A 2Repository: pyiron/executorlib
Length of output: 3797
Use
uv runto executepip checkwithin the uv-managed environment.Running plain
pip checkafteruv syncexecutes in the runner's default Python, not the uv-managed virtual environment. This defeats the purpose of the check. Additionally, explicitly specify Python 3.14 to align with the PR objective.Suggested fix
uv_check: needs: [black] runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 + - name: Setup Python + uses: actions/setup-python@v5 + with: + python-version: "3.14" - uses: astral-sh/setup-uv@v7 - name: Install the project and pip check shell: bash -l {0} run: | uv sync --all-extras --dev - pip check + uv run pip check🧰 Tools
🪛 zizmor (1.25.2)
[warning] 109-109: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[warning] 105-115: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block
(excessive-permissions)
[error] 109-109: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 110-110: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/pipeline.yml around lines 105 - 115, In the uv_check job workflow, the pip check command is running in the runner's default Python environment instead of the uv-managed virtual environment. Replace the direct `pip check` call with `uv run pip check` to execute it within the uv-managed environment. Additionally, add a step to explicitly specify and set up Python 3.14 before the uv setup to align with the PR objective, using the appropriate GitHub Actions setup-python action.
109-110:
⚠️ Potential issue | 🟠 Major🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/pipeline.yml | sed -n '100,120p'Repository: pyiron/executorlib
Length of output: 707
🏁 Script executed:
rg "uv_check" .github/workflows/pipeline.yml -B 5 -A 15Repository: pyiron/executorlib
Length of output: 1398
🏁 Script executed:
wc -l .github/workflows/pipeline.ymlRepository: pyiron/executorlib
Length of output: 97
🏁 Script executed:
head -20 .github/workflows/pipeline.ymlRepository: pyiron/executorlib
Length of output: 417
🏁 Script executed:
rg "on:" .github/workflows/pipeline.yml -A 10Repository: pyiron/executorlib
Length of output: 11617
Harden action references in
uv_checkby pinning to SHAs and disabling credential persistence.The
uses:entries are tag-based (@v4,@v7). For supply-chain hardening, pin action SHAs. Additionally, since this job performs read-only operations, setpersist-credentials: falseon checkout.Suggested fix
- - uses: actions/checkout@v4 + - uses: actions/checkout@<full_commit_sha_for_v4> + with: + persist-credentials: false - - uses: astral-sh/setup-uv@v7 + - uses: astral-sh/setup-uv@<full_commit_sha_for_v7>🧰 Tools
🪛 zizmor (1.25.2)
[warning] 109-109: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 109-109: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 110-110: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/pipeline.yml around lines 109 - 110, The `uv_check` job uses tag-based action references which pose security risks. Pin both the `actions/checkout@v4` action to its full commit SHA and the `astral-sh/setup-uv@v7` action to its full commit SHA for supply-chain hardening. Additionally, add the `persist-credentials: false` parameter to the checkout action since this job only performs read-only operations and does not need credential persistence.Source: Linters/SAST tools
src/executorlib/backend/interactive_serial.py (1)
15-15:
⚠️ Potential issue | 🟠 Major | ⚡ Quick winPublic API rename is breaking without a compatibility shim
main(...)appears to have been replaced byevaluate_cmd(...)at Line 15, which can break external callers importingexecutorlib.backend.interactive_serial.main. Please keep a backward-compatible alias/wrapper (at least for one deprecation cycle).Suggested compatibility patch
def evaluate_cmd(argument_lst: Optional[list[str]] = None): @@ while True: ... +def main(argument_lst: Optional[list[str]] = None): + """Backward-compatible alias for evaluate_cmd().""" + return evaluate_cmd(argument_lst=argument_lst) + if __name__ == "__main__": evaluate_cmd(argument_lst=sys.argv)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.def evaluate_cmd(argument_lst: Optional[list[str]] = None): # [existing function body remains unchanged] def main(argument_lst: Optional[list[str]] = None): """Backward-compatible alias for evaluate_cmd().""" return evaluate_cmd(argument_lst=argument_lst) if __name__ == "__main__": evaluate_cmd(argument_lst=sys.argv)🤖 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 `@src/executorlib/backend/interactive_serial.py` at line 15, The public function main() has been renamed to evaluate_cmd() without providing backward compatibility, which will break external code importing executorlib.backend.interactive_serial.main. After the evaluate_cmd() function definition, add a backward-compatible alias or wrapper function named main that calls evaluate_cmd() with the same arguments to maintain compatibility for at least one deprecation cycle.
2 participants
Summary by CodeRabbit