On 10/11/19, Jim Elphick <jelph...@onetechnologies.net> wrote: > I upgraded my Python 3.7.3 windows install to 3.7.4 using the windows > download from python.org. > > After the install, the keyword "python" will no longer invoke python. > "python3" also fails. "py" is now the only access to python.
"python3" would normally fail, unless it's Windows 10 and you installed the app distribution from the Microsoft Store. Apps execute via special links that get created in "%LocalAppData%\Microsoft\WindowsApps". The store distribution of Python creates a bunch of these links, including versioned names such as "python3.exe" and "python3.7.exe". > py -version returns Python 3.7.4 > python -version returns the following. The first is bash. > The second is from powershell > bash: python: command not found > python : The term 'python' is not recognized as the name of a cmdlet, You forgot to include the option to add Python to the environment variables. This can be fixed in the programs list in the control panel. Right-click the version that you want to change and select "change". Choose to modify the installation and click "next". Enable "add Python to environment variables". Note that this dialog also shows you where you installed Python in the greyed-out "customize install location" text box. The installer probably won't remove invalid paths that no longer work. So open the system environment variable editor and remove Python installation directories and "Scripts" subdirectories that are no longer valid or that you simply don't need in PATH. For good measure, also select the "Python Launcher" installation and choose to repair it. This will rewrite the Python.File progid and registered ".py" file association. That's not enough on its own, however. "Python.File" is not necessarily your user choice in the shell, which overrides the registered file association. So, to finish out, right-click a .py file; select the "open with" menu; and click on "choose another app". Select the Python app with a rocket in the icon and enable the toggle to "always use this app". Select ok. This should ensure that "Python.File" controls the open action and right-click actions for .py scripts, including the shell extension for drag-and-drop support and the "Edit with IDLE" menu. > This is much more than an inconvenience. Pip has stopped working because it > expects to find "python.exe". pipenv also no longer executes. > Pip -version returns (second is again powershell) > nothing in bash (empty string, no error) > Fatal error in launcher: Unable to create process using '"c:\program > files\python37\python.exe" The new installation was probably not an in-place upgrade but instead installed somewhere else, probably for the current user in "%LocalAppData%\Programs\Python\Python37". However files were left in the original "C:\Program Files\Python37\Scripts" directory, including a stale pip.exe, which was still in PATH. pip.exe is just a frozen script that's embedded in a scaled-down version of the py.exe launcher. The embedded script includes the path to python.exe in a shebang. That path was no longer valid. To confirm this in a case like this, run `where.exe pip` to determine what `pip` executes. You know from the installer where the current Python installation is located. Or you can determine it by running Python from the start menu and printing the value of sys.prefix. The correct pip.exe is in its "Scripts" subdirectory. -- https://mail.python.org/mailman/listinfo/python-list
