But the launcher does have value. Mainly because of how Windows handles the PATH and how it wants C:\Program Files to be organized; but there are enough fringe benefits that a core dev wants to bring it to Linux/Mac too (https://github.com/brettcannon/python-launcher).
"PEP 3147 – PYC Repository Directories" https://peps.python.org/pep-3147/ :
> Linux distributions such as Ubuntu [4] and Debian [5] provide more than one Python version at the same time to their users. For example, Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1, with Python 2.6 being the default. [...]
> Because these distributions cannot share pyc files, elaborate mechanisms have been developed to put the resulting pyc files in non-shared locations while the source code is still shared. Examples include the symlink-based Debian regimes python-support [8] and python-central [9]. These approaches make for much more complicated, fragile, inscrutable, and fragmented policies for delivering Python applications to a wide range of users. Arguably more users get Python from their operating system vendor than from upstream tarballs. Thus, solving this pyc sharing problem for CPython is a high priority for such vendors.
> This PEP proposes a solution to this problem.
> Proposal: Python’s import machinery is extended to write and search for byte code cache files in a single directory inside every Python package directory. This directory will be called __pycache__.
Should the package management tool also install multiple versions of the interpreter? conda, mamba, pixi, and uv do. Neither tox nor nox nor pytest care where the python install came from.
https://news.ycombinator.com/item?id=42347468
repairwheel: https://github.com/jvolkman/repairwheel :
> It includes pure-python replacements for external tools like patchelf, otool, install_name_tool, and codesign, so no non-python dependencies are required.
But it could and should have been redesigned at some point to include those kinds of things, sure. And the second best time to plant a tree is now.
Installations could be managed better on Windows, too. I can envision a cross-platform (rather, made separately available for each major platform) `py` tool which, on Windows, would set up Program Files with the `py` executable in an overall folder (added to PATH), and then subfolders where the actual Python version installations go. NTFS does support hard links and symbolic links (https://en.wikipedia.org/wiki/NTFS_links), so it could conceivably make the executables available directly, too. Then perhaps there could be a `py get` command to grab and run the installer for another version.
On Linux, of course, much the same, but using `/usr/{bin,lib}` in normal ways. Or perhaps `/usr/local/{bin,lib}`. (And the system would come with `py` as well as a specific Python version, and system scripts would have a `py -3.x` shebang.)
pip 0.2 (2008) https://pypi.org/project/pip/0.2/ :
> pip is complementary with virtualenv, and it is encouraged that you use virtualenv to isolate your installation.
https://pypi.org/project/pip/0.2/#using-pip-with-virtualenv :
pip install -E venvpath/ pkg1 pkg2
pip install --help | grep "\-E"> Python 3.3 included a standard library approach to virtual Python environments through the venv module. Since its release it has become clear that very few users have been willing to use this feature directly, in part due to the lack of an installer present by default inside of the virtual environment. They have instead opted to continue using the virtualenv package which does include pip installed by default.
"why venv install old pip?" re: `python -m ensurepip && python -m pip install -U pip` https://github.com/python/cpython/issues/74813
Though `pip install --python=... pkg` won't work ( https://github.com/pypa/pip/pull/12068 ),
Now, there's
pip --python=$VIRTUAL_ENV/bin/python install pkg