Hi there,
I am the key-driver of devonfw-ide a cool tool to automate the setup of development environments for software development projects.
We received demands to support python, pip and tools based on this so we already implemented this feature.
However, our challenge is that we want to create a sandbox environment where each tool lives in its own folder and can be updated independently or simply be removed by deleting its folder.
While this works awesome for tools like java, maven, dotnet, github-cli, helm, terraform, etc. this does not go well together with the philosophy of python and pip that by design want to install python based tools inside the “python/pip” installation itself. Also I was wondering why Python/pip on windows tries to enforce a folder named “Scripts” with executables to be in the PATH instead of following POSIX and name it “bin” instead but renaming causes severe errors…
To avoid ending up like homebrew I wanted to ask for help here so we create something that helps to bring python to end-users easily without breaking things or getting in the way.
Could someone give some guidelines how we should archive this:
Should we redundantly install python alongside with every tool based on python so each tool can choose its own python version and side-effects are guaranteed to be avoided?
Would you instead recommend to use virtualenv and if so could you give us some hints how to archive it this way?
Is there by any chance a way to get portable binary distributions of python for all major OS in the future as building from the source-code is nothing that seems to work stable (e.g. max see our issue #907 - sorry no link left for my merrit)? In this forum I found a thread about pymac that already looks promising. In case for Linux there is also some way to solve it, please let me know…
In case there is existing documentation answering my questions I am more than happy to receive a simple link as answer but I could not easily find this whilst digging the docs…
Thanks in advance
Jörg
In addition to the other replies, try the --python option which was
just added in pip 22.3, since it allows an external copy of pip to
install things into any reachable Python environment. You could use
it to install something into a venv without having to call a copy of
pip inside that venv:
Considerate historical baggage at this point. Otherwise POSIX != Windows and Windows has its own practices to follow to be good Windows citizens.
By “tool” you mean Python tools? That is one solution.
Virtual environments are just a bunch of symlinks and folders (on Unix). If things are always going to be in the same spot they were when you created the virtual environment (both the Python environment and where you are going to extract the virtual environment), you can zip them up. But otherwise virtual environments are not designed to be relocatable, but instead and quick and cheap enough to create on demand.
If you just want a portable package for Windows, check out the nuget.org packages. We try to keep the focus on the Store package and regular installer because most users will avoid trouble by using them, but those who know what they’re doing often benefit from a package that integrates with other build tools.
Thanks for all your answers and hints. It is really astounding how many helpful answers I got in such a short time. I will study all the things and am quite sure that I will be able to find a solution.
FYI: We are not creating a “global” installation that is centrally installed into the OS (Windows with Registry keys, Linux, MacOs) and global PATH variable. The idea is to have real sandboxes where you can have as many of them side-by-side on the same machine all with their own version of python or whatever tools.