New GitHub issue #114881 from zooba:<br>

<hr>

<pre>
For a per-user install of the launcher (the current default), we have a user-writable directory on PATH. We could use this in combination with the launcher to support an "activate" command that reliably puts a selected version of Python on PATH for you without adding the actual install directory.

For example (note that this is hypothetical and fake right now):

```
C:\> dir C:\Users\USERNAME\AppData\Local\Programs\Python\Launcher

Mode LastWriteTime         Length Name
---- -------------         ------ ----
-a----         12/7/2023  10:20 PM 765208 py.exe
-a----         12/7/2023  10:21 PM          50968 pyshellext.amd64.dll
-a----         12/7/2023  10:20 PM         763672 pyw.exe

C:\> py -V:PythonCore/3.12 --activate
Activated Python 3.12 (Store)

C:\> dir C:\Users\USERNAME\AppData\Local\Programs\Python\Launcher

Mode LastWriteTime         Length Name
---- -------------         ------ ----
-a----         12/7/2023  10:20 PM 765208 py.exe
-a----          2/1/2024   9:32 PM             61 py.ini
-a----         12/7/2023  10:21 PM          50968 pyshellext.amd64.dll
-a----         12/7/2023  10:20 PM         765208 python.exe
-a----         12/7/2023  10:20 PM         765208 python3.exe
-a----         12/7/2023  10:20 PM         763672 pythonw.exe
-a----         12/7/2023  10:20 PM         763672 pythonw3.exe
-a----         12/7/2023  10:20 PM         763672 pyw.exe
```

My thinking here is that we add a new section to `py.ini` that converts the launcher `argv[0]` into a Company/Tag value (equivalent of passing `-V:`). We need a new section to avoid conflicting with existing shebang commands, but should be able to write it from the launcher call easily enough. We'd get to decide whether to use this new mapping to override shebang lines and environment variables (gut feel is to ignore shebangs but honour env vars).

An alternative to the `py.ini` section would be a `python.exe.ini` adjacent to the executable and specific to it, so we create a few more files, but have a much simpler time handling them.

We should also have a `py --deactivate` option to remove the files. `py --activate` would activate the interpreter that is launched for just `py` (that is, with `--activate` we do the normal search but instead of launching it, we write it into a config file and ensure the global names exist).

Per-machine installs would require admin privileges to do this, as they're in a per-machine directory. I think that's okay - we can have a helpful error message.
</pre>

<hr>

<a href="https://github.com/python/cpython/issues/114881">View on GitHub</a>
<p>Labels: type-feature, OS-windows</p>
<p>Assignee: </p>