Title: Installing Py on Windows: Need to restart or logout for path to be added
Type: enhancement Stage: resolved
Components: Installation, Windows Versions: Python 3.8, Python 3.4, Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: docs@python Nosy List: John Palermo, docs@python, eryksun, forrestshields2, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2015-07-30 17:55 by John Palermo, last changed 2020-09-24 23:20 by eryksun. This issue is now closed.

Messages (6)
msg247688 - (view) Author: John Palermo (John Palermo) Date: 2015-07-30 17:55
Something I suppose many new users could stumble over: After installing Python and trying out "pip" or "python" on the command line nothing is found. You have to re-start Windows or re-log into your account.

I suggest adding this information to the documentation here

and also adding it to the Windows installer description for the "add Python to your path" option.
msg247691 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2015-07-30 19:50
I think a custom action can be added to Tools/msi/msisupport.c to send a [WM_SETTINGCHANGE][1] "Environment" message to top-level windows. This makes Explorer reload its environment from the registry, so starting a new command prompt (cmd.exe) from Explorer will see the updated PATH. 

msg247757 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-07-31 17:07
That's exactly what is needed (though it still won't affect command prompts that are already open).

The 3.5+ installer does it, so this only affects 2.7 and 3.4.
msg377449 - (view) Author: Forrest Shields (forrestshields2) Date: 2020-09-24 16:01
As of 3.8.5 the current shell's PATH is outdated after a commandline system-wide installation.  This makes it very difficult to do a scripted install of Python followed by the `python` or `pip` commands, as they will not be found. In addition to modifying the PATH in the system scope, the PATH should also be modified for the current process (shell).

Here is the WORKAROUND I created and am currently using:

1. Perform the commandline system-wide installation from an Administrative PowerShell prompt.
2. After the installation (but before using `python` or `pip`) rebuild the PATH environment variable for the current process from the concatenation of the PATH environment variables from the System and User scopes (this is how Windows builds the PATH) by using this code:
[Environment]::SetEnvironmentVariable('PATH', [Environment]::GetEnvironmentVariable('PATH', 'Machine') + ';' + [Environment]::GetEnvironmentVariable('PATH', 'User'), 'Process')
msg377453 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-09-24 18:03
Sorry, but we don't have any way to update the current terminal process. We already update the current shell, so if you start a new terminal/Powershell/cmd/etc. instance it should have the updated variable. 

The workaround you posted is fine. Directly adding the new install to the current PATH is also okay.
msg377468 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2020-09-24 23:20
> We already update the current shell, so if you start a new 
> terminal/Powershell/cmd/etc. instance it should have the 
> updated variable. 

The installer broadcasts an "Environment" message to top-level windows. In practice, only Explorer listens for and reloads its environment for this window message. For most programs, a new instance has to be run from Explorer in order to get the updated environment. 

CMD and PowerShell don't own any windows, so they cannot get this message in principle. The console-session host process (conhost or openconsole) may own a top-level window if it wasn't allocated with CREATE_NO_WINDOW and wasn't created as a ConPTY server (e.g. under Windows Terminal). But the console doesn't have a console control event for this case (e.g. something like a hypothetical CTRL_ENVIRONMENT_EVENT) that it sends to client processes. It's assumed that console applications that need to interact with the desktop environment will create at least a hidden window.

Without the "Environment" message, it's still possible for the user to run a script that reloads the environment in place in CMD or PowerShell. The environment has to be loaded in four passes: system REG_SZ values, system REG_EXPAND_SZ values, user REG_SZ values, and user REG_EXPAND_SZ values. User values should always be able to depend on system values, and REG_EXPAND_SZ values should always be able to depend on REG_SZ values. This is the way WinAPI CreateEnvironmentBlock has always worked. When reloading PATH, this is an issue if a new machine PATH value depends on new/modified REG_SZ system variables or if a new user PATH value depends on new/modified system variables or new/modified REG_SZ user variables.
Date User Action Args
2020-09-24 23:20:17eryksunsetmessages: + msg377468
2020-09-24 18:03:48steve.dowersetstatus: open -> closed
resolution: out of date
messages: + msg377453

stage: resolved
2020-09-24 16:01:53forrestshields2setversions: + Python 3.8
nosy: + forrestshields2

messages: + msg377449

components: + Installation
2015-07-31 17:07:56steve.dowersetmessages: + msg247757
versions: + Python 3.4
2015-07-31 06:15:26ned.deilysetnosy: + tim.golden, paul.moore, zach.ware, steve.dower
components: + Windows, - Documentation
2015-07-30 19:50:28eryksunsetnosy: + eryksun
messages: + msg247691
2015-07-30 17:55:15John Palermocreate