I would like to install Python in a new location, completely separate and not affecting an existing installation of the same version. 

Despite I use /TargetDir=newdir, the installer goes into the "Modify Setup" dialog. If I chose "Modify", it shows my TargetDir read-only in the Customize installation location, but then modifies the original installation. 

If I run it with /passive or /quiet, it also modifies the existing installation instead of creating a new one at /TargetDir (doing nothing, since there is nothing to modify).

If I choose repair at the prompt, it installs the Debug version (only!) into the TargetDir, with no library files except venv\scripts\nt (containing the debug .exe). 

It seems the installer checks whether there is an existing installation based on the registry (or by other means such peeking into the default installation directory). If there is an existing installation, the  /TargetDir seems to be ignored, except for the peculiar repair installation of the debug build (which I never asked for).

I believe this to be a bug in the installer; however if ignoring the /TargetDir once an existing installation is found (which I do not find desirable), it should be documented. 

The /TARGETDIR option of the old .msi installer didn't have this problem, it would reliably install into the target dir.

Windows Version is Windows 10, version 1803 (build 17134.1726).

Unfortunately, this is deliberate, or at least deliberate enough to not consider it a bug.

The installer from python.org is intended to only support a single install per-machine.

In general, if you simply copy the installation folder to a new location it will be isolated from the first. However, there are some circumstances where this is not the case (unless you take additional steps to isolate it, such as adding a ._pth file).

If you can share a bit more about what you're trying to achieve, we may be able to suggest an alternative approach. Otherwise, you may need to find another distribution/installer of CPython.

Thank you, Steve, for your rapid response and explanation!

I would like to have my installation fully isolated in case somebody (running the machine) fiddles with the installation in the standard location. I used to do that without problems with the 2.7 .msi installer, but now I’ve finally almost finished converting to 3.8 (I know I’m late) and that approach doesn’t work any longer.

I tried to reverse engineer it a bit by looking at the log files and zapping the registry entry HKLM\Software\Python\PythonCore\3.8 (for an all-users install), with no success. Modify or repair would randomly install some stuff in the target dir and other stuff into a previous installation. The Windows Installer technology seems to be rather implicit than explicit. How does it detect the previous installation’s location?

Although it’s not a bug and an /isolated mode doesn’t seem to be feasible, perhaps it could check and warn that /targetdir is being ignored. The doc could mention that it’s intended only for a single installation per version per machine.  

And thank you again for your contributions to make Python on Windows such a joy – highly appreciated! 
Martin

So for a manually managed install, your best bet is to just copy the install directory somewhere else (and then maybe remove the original? Up to you). That will break the MSI tracking that lets us do reliable upgrades and repairs, but shouldn't break Python itself.

If you're planning to include it in another application, you may want to look at the embeddable distro, which is reduced in size/scope for this purpose (it generally also requires a regular install for build/pip installs).

Basic levels of fiddling can also be avoided by using virtual environments. Nothing much we can do will protect against really dedicated (or malicious) fiddling, but using the MSI installs we have means that a repair should quickly fix it up.

Thanks again Steve. 

I will copy the installation. I require a lot of pip packaged, so the embeddable distro doesn't look right for my case. 

I still think the /targetdir should issue some kind of warning if used with an existing installation, but this is obviously lowest prio.