Windows installer prohibits different patches for the same version.
I do not see any reason why the installer cannot put two different versions, e.g. 3.9.4 and 3.9.6 into different folders.
This makes it very difficult to debug issues introduced in higher versions. Please allow installation of different patches into separate folders.

To debug pure python, use embeddable pythons in different folders and copy Lib folder from source archive instead of using python3.9.zip.

When using msvc (python3*.lib), I think it's enouth to install python as follows or build from source.

1.Copy Installed Python to any folder.
2.Uninstall Python.
3.Install Python with different minor version.

Why does it have to be so complicated? What is the rationale behind prohibiting different patches in separate folders?

> Why does it have to be so complicated? What is the rationale behind prohibiting different patches in separate folders?

Most users don't want different patches in separate folders - they want to update to the latest and greatest and use it everywhere.

Those users who *do* want different versions tend to be well-informed enough to figure out alternatives.

You can also grab the packages from https://www.nuget.org/packages/python/ which can be extracted anywhere you like and are not stripped down like the embeddable package.

Unfortunately I am not so enlightened to figure out how to do it on my own, and python.org obviously wants to keep it secret. I am also not on a friendly basis with kami-sama and don't know what other users want, but the common sense tells me that having an option to do do something should not hurt anyone.

You found your way to the issue tracker where we can help, which is more enlightened than most of our other ~20 million users :)

Nuget allows you to download the packages directly. Go to the page I linked and choose your version, then find the download link. They have a bit more structure in the ZIP file than just a Python runtime, to enable them to interoperate properly with a Nuget-based build system (relatively common on Windows these days), but you can move the contents around however you like.

And unfortunately, any "options" are not free. Someone has to develop, document, test, maintain and support it, and everyone who's been willing to do it has chosen to do it independently from the core team (which is great! CPython is free open-source software for exactly that reason). Perhaps Anaconda would suit your needs better?

Hi Steve,

Thank you for taking time to reply. I do appreciate it.

I did try nuget installs but they a little bit weird for my taste.
Anaconda is too bloated.
I also tried python-webinstall.exe /layout and install from .msi, these
work OK for the command line use, but do not work with Vim plugins for some
reason, so I cannot rely on them as I can on a normal Windows install.

As a side note, I think making the install restrictive is more work than
just let it install where user wants to install. The restrictions need to
be coded - don't they? :)

Konstantin

чт, 8 июл. 2021 г. в 03:28, Steve Dower <report@bugs.python.org>:

>
> Steve Dower <steve.dower@python.org> added the comment:
>
> You found your way to the issue tracker where we can help, which is more
> enlightened than most of our other ~20 million users :)
>
> Nuget allows you to download the packages directly. Go to the page I
> linked and choose your version, then find the download link. They have a
> bit more structure in the ZIP file than just a Python runtime, to enable
> them to interoperate properly with a Nuget-based build system (relatively
> common on Windows these days), but you can move the contents around however
> you like.
>
> And unfortunately, any "options" are not free. Someone has to develop,
> document, test, maintain and support it, and everyone who's been willing to
> do it has chosen to do it independently from the core team (which is great!
> CPython is free open-source software for exactly that reason). Perhaps
> Anaconda would suit your needs better?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue44575>
> _______________________________________
>

> As a side note, I think making the install restrictive is more work than
just let it install where user wants to install. The restrictions need to
be coded - don't they? :)

Well at this point, the restrictions already exist! So change it now is the expensive part.

And having two ways to do something will always be more complicated than one way. We can't abandon the existing installation methods.

Some quotes from my reply to an off-list email that may be useful for other people who encounter this issue:

---

Apps that use Python-based plugins we can't make Just Work - it's up to the host application to work with Python installs (or to bundle its own, which is easier on Windows). We're happy to help the people who can fix it on their side if you know who to work with.

Rather than developing our own installer, it's actually less effort to use the standard Windows Installer service to manage installs, and that's the system with the restrictions. Coding something from scratch that supports the equivalent upgrade/repair/uninstall mechanisms would be considerably more work, and we'd end up basically reimplementing it or end up regularly recommending people try and delete everything by hand.

We also support the newer Windows MSIX format via the Store, because that's even less work and is a better experience for most users. Unfortunately, it's even further away from what you want. If your preferences are so strong, you may need to do your own builds and manually put them where you need. The Nuget packages will let you skip the compile step, and the regular ones will let you also skip the "put them where you need" step.

Huh, interesting that the email reply is identical to the one above from Константин, but the email I received had no reference to bpo in it...

Okay, consider my reply above identical to the one I sent off list :)

After reviewing all the suggested options of the "versioned" Windows install I came to the conclusion that the "NuGet" path is the easiest.
Assuming x - version, y - patch number, the following steps work

1. Unzip 'Tools' folder of the NuGet archive into Python\3xy
2. Re-install pip to add pip.exe to Python\3xy\Scripts

3xy\python.exe -m pip install -U pip --force-reinstall

It works like a regular install after that.

Switching between versions can be done via a symbolic link:

cmd /c mklink /d 3x 3xy

Optional: Add Python\3x\Scripts;Python\3x to the PATH env variable.