# Pre-PEP: A Python Installation Manager for Windows **URL:** \ **Category:** Ideas\ **Created:** [December 17, 2024, 7:26pm UTC](https://discuss.python.org/t/pre-pep-a-python-installation-manager-for-windows/74556 "2024-12-17T19:26:52Z")\ **Posts on this page:** 1\ **Showing post:** 65
**Author:** ![kapinga](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/kapinga/32/24087_2.png) [@kapinga](https://discuss.python.org/u/kapinga)\ **Post date:** [January 10, 2025, 3:12pm UTC](https://discuss.python.org/t/pre-pep-a-python-installation-manager-for-windows/74556/65 "2025-01-10T15:12:39Z")
In general, Paul’s scenarios align more with my intuition, but I also recognize that I’m, personally, much closer to his Scenario 2 than Scenario 1. (In full disclosure: I’ve never internalized using the `py` command, and, much worse, have python installs managed by `conda`, the official python installer, `uv`, and perhaps even a couple from `pyenv-win`. Suffice to say that I’m _very_ excited by the idea of an official installation manager on Windows.) As a user, what I’d love to see in the long term is a well thought out, unified set of commands that apply to all the major platforms for user-provided python scripts (i.e., Windows, OSX, and Linux at minimum). Someone above brought up rust and `cargo`, which I think is a reasonable analogy (although there are also clear differences). As I understand it, that design has three fundamental parts: `rustc` (the compiler), `cargo` (the environment manager), and `rustup` (the version manager/installer/upgrade tool). If we analogize this to Python, one can imagine a similar trio of `python` (the interpreter), `py` (the environment manager), and `pymanage` (the version installer/upgrade tool). However, a key part of what makes the rust trio of commands work is that they work _everywhere_. As a Windows user, I don’t have to worry (too much) if a rust article/blog/document was written by a Windows user or a Unix one; the guidance around how to “do stuff” is the same. That’s not the case in Python currently: Windows users are instructed to run Python via the `py` command, while the rest of the world uses `python` or `python3` (and I don’t expect random blog posts to show two versions of every command snippet). Similarly, there’s [complaints about the lack of an official Python installer on Linux](https://discuss.python.org/t/publish-linux-installer-on-python-org/53760), which, if I understand correctly, largely centers around the (entirely reasonable) desire to not break the distro’s system installed python or scripts. While I don’t expect this release to _solve_ this issue in one go, it would be a sorely missed opportunity if this proposal is not thought through with a long-term, cross-platform goal in mind. The easiest way to keep the clean separation is to have separate commands that are (mostly) used to perform the separate activities listed above (as others have noted, imbuing `python` on with special install powers is likely a non-starter on Linux). Reading through Steve’s recent description of the technical constraints is helpful, and I get the “first use” challenge. If the Windows implementation of the `python` command needs a special ability to install an interpreter to handle the first use scenario, that’s fair enough - but this ability should ideally be disabled as soon as a functional interpreter is found or, as a poor second, strongly discouraged in the documentation. I’m probably too naive, but I can imagine an implementation that has the `python`, `py`, and `pymanage` aliases all point to the same executable, and then have that executable determine its behavior based on the name it was called by and whether or not it was able to find an installed interpreter. However, it should be a goal to make sure that, outside of the first use, `python` behave the same as it does when called from within a `venv` or on non-Windows systems. --- _[View the full topic](https://discuss.python.org/t/pre-pep-a-python-installation-manager-for-windows/74556)._