Huh. Come to think of it, when I was on Windows (through 2021) I got used to using `python` rather than `py` while using venvs, even though it was apparently no longer necessary after I upgraded from Python 3.4. This announcement totally missed me. But also it was easier to internalize "always use venvs, and always run `python`, and that way you won't have to change the instructions for Linux/Mac". And that worked out beautifully.
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).
It seems to me py launcher could have done the same thing as uv such as downloading and setting up python and managing virtual environments.
It may that there were so many distros of Python by the time that venv (and virtualenv and virtualenvwrapper) were written.
"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.
And then of course cibuildwheel builds binary wheels for Win/Mac/Lin and manylinux wheels for libc and/or musl libc. repairwheel, auditwheel, delocate, and delvewheel bundle shared library dependencies (.so and DLL) into the wheel, which is a .zip file with a .whl extension and a declarative manifest that doesn't require python code to run as the package installer.
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.
The launcher first appeared with Python 3.3. There was nothing like the python standalone build project at that point, and `venv` had also just been added to the standard library in the same version.
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 used to support virtualenvs.
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""PEP 453 – Explicit bootstrapping of pip in Python installations" https://peps.python.org/pep-0453/#changes-to-virtual-environ... :
> 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
> When was the -E <virtualenv> flag removed from pip and why?
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