#39: pip commandlet

[hohwille]

This PR fixes #39

Implemented changes:

• This is a fork of PR #39: implement pip commandlet #1597 so credits go to @maybeec since I took over his work
• However, I implemented PR #39: refactoring to extract package-manager logic out of node/npm #1638 and reused this to share common logic between node/npm and uv/python/pip since both worlds use a package manager that we use instead of our default installation routines.
• I was able to cause so problems bugs in some edge-cases with the current state of #39: implement pip commandlet #1597 (e.g. install python, install pip, uninstall uv, run pip, bang)
• Also I now give the option to the user to decide if he wants to use the "real pip" or the emulated "uv pip". IMHO end users will typically expect that ide pip «args» is doing the same thing as pip «args» as we promised in our documentation. Therefore I am still thinking if the default should actually be the "real pip" - currently I made uv be the default.

---

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summarizes what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
  with internal

Checklist for tool commandlets

Have you added a new «tool» as commandlet? There are the following additional checks:

• The tool can be installed automatically (during setup via settings) or via the commandlet call
• The tool is isolated in its IDEasy project, see Sandbox Principle
• The new tool is added to the table of tools in LICENSE.asciidoc
• The new commandlet is a command-wrapper for «tool»
• Proper help texts for all supported languages are added here
• The new commandlet installs potential dependencies automatically
• The variables «TOOL»_VERSION and «TOOL»_EDITION are honored by your commandlet
• The new commandlet is tested on all platforms it is available for or tested on all platforms that are in scope of the linked issue

[coveralls]

Pull Request Test Coverage Report for Build 20007288351

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 183 unchanged lines in 6 files lost coverage.
• Overall coverage decreased (-0.1%) to 70.003%

---

Files with Coverage Reduction	New Missed Lines	%
com/devonfw/tools/ide/tool/ide/IdeToolCommandlet.java	1	78.33%
com/devonfw/tools/ide/variable/IdeVariables.java	1	95.74%
com/devonfw/tools/ide/commandlet/CommandletManagerImpl.java	8	90.0%
com/devonfw/tools/ide/context/IdeContext.java	19	74.6%
com/devonfw/tools/ide/tool/LocalToolCommandlet.java	24	81.03%
com/devonfw/tools/ide/context/AbstractIdeContext.java	130	67.91%

Totals
Change from base Build 20003978026:	-0.1%
Covered Lines:	10030
Relevant Lines:	13775

---

💛 - Coveralls

[maybeec]

Nice @hohwille ! Thanks. Just one question:

Also I now give the option to the user to decide if he wants to use the "real pip" or the emulated "uv pip".

Is there any option to stay in control as a settings admin over all installations to not end up in different behaviors on the team's machines as some chose so, some others ?

[hohwille]

Is there any option to stay in control as a settings admin over all installations to not end up in different behaviors on the team's machines as some chose so, some others ?

First of all the project settings can define this via

PIP_EDITION=uv

vs.

PIP_EDITION=pip

The general configuration philosophy of IDEasy is that users can override things in their conf/ide.properties.
By doing so you take control but also responsibility ("With great power comes great responsibility").
Typically the average IDEasy user never does things like this unless he was told so by others.
So to what I observed the users only override stuff there when there is a real purpose to do so.
The bigger problem is IMHO if users do override something, they easily forget about this and months or years later this may become a problem.
We support the command ide -d env to get a quick overview of your configurations and where they originate from.

IMHO it is not a good idea to give 100% control to an "IDE admin".
This is from a command and conquer thinking.
User should have the last word and "manual override" like the pilot of a plane can overrule the auto-pilot.