Repository navigation
#2561: Make python a pristine versioned tool with per-project venv is… - #2623
Open
krystynaShatkovska wants to merge 10 commits into
Open
krystynaShatkovska wants to merge 10 commits into
krystynaShatkovska wants to merge 10 commits into
Conversation
…venv isolation Install python as a pristine, versioned interpreter once into the shared software repository ($IDE_ROOT/software/default/python/python/<version>), shared across projects, and route each project's global packages into a per-project virtual environment (IDE_HOME/.venv) so projects no longer collide (devonfw#352). The uv tool store is likewise per-project (IDE_HOME/.uv-tools). Add a python launcher (Bash and PowerShell) that routes to 'ide python' inside a project and falls back to the system python outside, mirroring the existing node/npm/claude functions.
Collaborator
Coverage Report for CI Build 41044692055Coverage decreased (-0.04%) to 75.245%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions41 previously-covered lines in 4 files lost coverage.
Coverage Stats
💛 - Coveralls |
…avadoc Fix code-review findings on the python pristine tool: - create the "Scripts"->"bin" symlink for the per-project virtual environment on Windows (previously only the pristine interpreter got it) so the venv "bin" PATH entry from setEnvironment resolves on all platforms. - rewrite UvTest.testSetEnvironmentWithNullIdeHome to exercise the actual getIdeHome() guard instead of the obsolete getSoftwarePath() one. - correct the stale "virtual environment" @PARAM javadoc to the Python installation.
QuangAnhLe
reviewed
Oct 14, 2026
QuangAnhLe
left a comment
QuangAnhLe
left a comment
Contributor
There was a problem hiding this comment.
@krystynaShatkovska Thanks for the PR! Looks good overall. I’ve left a few comments for you to take a look at.
…, add python3 - Stop priming ruff as a side effect of `ide install python`: gate it behind a new opt-in variable PYTHON_INSTALL_RUFF (default off) so a linter is not pushed onto every project. - Windows fix: a pristine interpreter keeps its executable in the installation root (Scripts/ is empty), so no "bin" symlink is created for the interpreter (which would otherwise shadow the real python.exe). The "bin" symlink is only created for the per-project venv, where Scripts/ genuinely holds the exe. - Add a python3 wrapper (bash functions + PowerShell) mirroring python. - Add a Windows-layout regression test (driven by a UV_LAYOUT=windows env var so the shared uv mock emits the Windows layout on any host).
QuangAnhLe
reviewed
Oct 14, 2026
QuangAnhLe
left a comment
QuangAnhLe
left a comment
Contributor
There was a problem hiding this comment.
hi @krystynaShatkovska, thanks for your fix. They look gut. There is only a problem in Uv.Java: Line 124-125. Can you maybe see it ?
The uv tool store was moved from the per-project software folder (<IDE_HOME>/software/python/tools, see devonfw#1518) to <IDE_HOME>/.uv-tools to make it per-project (see devonfw#352), but previously installed uv tools were left behind. On setEnvironment, one-time migrate the legacy store into .uv-tools: move it if the new store is free, back it up if the new store already holds tools. Best effort and never fails the environment setup.
Keep the per-project virtual environment design (devonfw#2561): setEnvironment points VIRTUAL_ENV and UV_PROJECT_ENVIRONMENT at IDE_HOME/.venv (the venv created by setupProjectEnvironment), not at the shared pristine interpreter from devonfw#2701. Pointing uv at a per-project venv does not break uv projects, so the devonfw#2701 regression does not apply here; taking upstream's side would orphan the whole per-project venv + Windows bin symlink logic this branch introduces.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes #2561
Implemented changes:
Change 1
Install python as a pristine, versioned interpreter once into the shared software repository at $IDE_ROOT/_ide/software/default/python/python/«version», using the same default-repository layout as other pristine versioned tool node. One copy of a version is now shared across all projects instead of each project owning its own copy.
Change 2
Route each project's global packages (pip, ruff, …) into a per-project virtual environment at IDE_HOME/.venv (created with uv venv backed by the pristine interpreter and seeded with pip), so two projects on the same interpreter no longer collide, addresses Design for tools like node and python that hack their own installation #352.
Change 3
Move the uv tool store to be per-project as well (IDE_HOME/.uv-tools) instead of living under shared software/python, so uv-managed tools also don't leak between projects.
Change 4
Add a python launcher in cli/src/main/package/functions (Bash) and functions.ps1 (PowerShell), mirroring the existing node/npm/claude functions: inside a project it runs ide python, otherwise it falls back to the system python.
Change 5
Update the uv/pip test-project fixtures and rewrite the Python/Uv tests to assert the new pristine + per-project-venv layout.
Testing instructions
Unit tests. From the cli module run:
cd cli && mvn
-Dtest='PythonTest,UvTest,PipTest,PipBasedIdeToolCommandletTest,RuffTest,SpyderTest,JustTest' test
All should pass. PythonTest.testInstallCreatesPristineInterpreterAndPerProjectVenv asserts the interpreter lands in the software repo (real path ends in 3.14.6) and the venv exists under IDE_HOME/.venv. testInstallKeepsPerProjectVenvIsolated asserts re-installing the shared interpreter does not wipe a project's installed packages (the Design for tools like node and python that hack their own installation #352 fix).
Manual (inside a project). With two separate projects configured to use python:
ide python --version # uses the pristine interpreter via the new launcher
python --version # in a project: routes to
ide python; outside a project: system pythonpip install requests # installs into IDE_HOME/.venv (per-project)
Then in a second project run pip install requests. Verify it does not see the first project's packages (isolation). The pristine interpreter path should be $IDE_ROOT/_ide/software/default/python/python/«version» and be identical (one shared copy) for both projects.
Full quality gates. mvn -q verify -pl '!documentation' from the repo root (build + tests) and
mvn checkstyle:check on the changed files both pass.
Checklist for this PR
Make sure everything is checked before merging this PR. For further info please also see
our DoD.
mvn clean testlocally all tests pass and build is successful#«issue-id»: «brief summary»(e.g.#921: fixed setup.batand notfeature/921 fixed setup.bat).If no issue ID exists, title only.
In Progressand assigned to you or there is no issue (might happen for very small PRs)with
internalpom.xmlfiles or otherwise if runtime dependencies changed,you have updated our LICENSE.adoc