[issue29586] Cannot run pip in fresh install of py 3.5.3
New submission from Adrian Chan: I uninstalled python 2.7 and 3.4, then performed a fresh install of 3.5.3. Running pip with `python -m pip` as per https://docs.python.org/3.5/installing gives the following error: C:\Python\Python35-32\python.exe: No module named pip.__main__; 'pip' is a package and cannot be directly executed Installation details: * win 7 64 bit. * python 3.5.3 32 bit. * chose options for pip, tcl/tk/idle, test suite, py launcher, shortcuts, add to env, precompile std lib. * installed to non-standard directory. ---------- assignee: docs@python components: Documentation, Installation, Windows messages: 287986 nosy: Adrian Chan, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cannot run pip in fresh install of py 3.5.3 type: behavior versions: Python 3.5 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Eryk Sun added the comment: Please provide the complete traceback. Copy and paste it from the command prompt. Also, include the fully-qualified path for what "python" runs, e.g. run `where python` in the command prompt. Also, include the value of the environment variables PYTHONHOME and PYTHONPATH, e.g. run `echo %PYTHONHOME% & echo %PYTHONPATH%` in the command prompt. ---------- nosy: +eryksun _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Adrian Chan added the comment: There is no traceback, that is the entirety of the output of the command. Python bin is C:\Python\Python35-32\python.exe PYTHONHOME is not set. PYTHONPATH is C:\python27\lib\site-packages\ I don't know why PYTHONPATH was set. I cleared it but it made no difference -- same error. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Eryk Sun added the comment: That error looks like __init__.py[c] was left in "C:\python27\lib\site-packages\pip". Just to be sure, since I don't know what you did to clear the value, please run `set PYTHONPATH=` to clear the value for the current shell. Then try `python -m pip`. When you modify or remove an environment variable using the control panel dialog, it broadcasts a window message that causes Explorer to reload its environment. Generally console applications such as cmd.exe do not own a top-level window (the console window is owned by conhost.exe) and thus cannot see this broadcasted message. To get the updated environment, you have to run a new instance of cmd from Explorer. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Adrian Chan added the comment: Thanks, but I know how to drive a terminal ;) Your hunch was basically correct though. I ran again with `python -v -m pip` (see with_pip_dir.txt), and see that python is attempting to import pip from my user directory (C:\Users\amc2\pip). This is an empty directory, except for an old pip log file from 2.7. If I rename the directory to something unrelated, `python -m pip` just fails with: C:\Python\Python35-32\python.exe: No module named pip. So mystery 1 is solved. I've definitely selected the pip option in the python installer. I also repaired the installation, with the pip option selected, and the error still remains. Where is pip supposed to be located on a win7 install? ---------- Added file: http://bugs.python.org/file46642/import_logs.tar.gz _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Eryk Sun added the comment: pip should be installed in site-packages, which for you is "C:\Python\Python35-32\Lib\site-packages". Try manually running ensurepip to make sure pip is installed: python -m ensurepip --verbose --upgrade --default-pip ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Adrian Chan added the comment: It's all working fine now, thanks. If one of the installer/windows guys wants to dig more into why this didn't install properly I'm happy to run things in my environment as necessary. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Eryk Sun added the comment: If you have the 3.5 installation logs in your %TEMP% directory, please zip them up and attach them to this issue. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Adrian Chan added the comment: Install logs attached. First set from initial install, second set from repair. ---------- Added file: http://bugs.python.org/file46645/py_install_logs.tar.gz _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Eryk Sun added the comment: The original install failed with the status code STATUS_DLL_NOT_FOUND (0xC0000135), as reported in "Python 3.5.3 (32-bit)_20170217102132_008_pip_JustForMe.log": MSI (s) (88:D8) [10:22:59:574]: Executing op: ActionStart(Name=UpdatePip,,) MSI (s) (88:D8) [10:22:59:575]: Executing op: CustomActionSchedule( Action=UpdatePip,ActionType=1089, Source=BinaryData,Target=CAQuietExec, CustomActionData="C:\Python\Python35-32\python.exe" -E -s -m ensurepip -U --default-pip) MSI (s) (88:C4) [10:22:59:588]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI2C60.tmp, Entrypoint: CAQuietExec MSI (s) (88:B0) [10:22:59:588]: Generating random cookie. MSI (s) (88:B0) [10:22:59:590]: Created Custom Action Server with PID 6212 (0x1844). MSI (s) (88:A8) [10:22:59:630]: Running as a service. MSI (s) (88:A8) [10:22:59:631]: Hello, I'm your 32bit Impersonated custom action server. CAQuietExec: Error 0xc0000135: Command line returned an error. CAQuietExec: Error 0xc0000135: QuietExec Failed CAQuietExec: Error 0xc0000135: Failed in ExecCommon method MSI (s) (88:D8) [10:22:59:658]: Executing op: End(Checksum=0, ProgressTotalHDWord=0,ProgressTotalLDWord=287056) CustomAction UpdatePip returned actual error code 1603 but will be translated to success due to continue marking Did your system require a reboot for Python 3.5 to work?
From what I can see in "Python 3.5.3 (32-bit)_20170217131555_007_pip_JustForMe.log", it looks like the repair skipped installing pip.
MSI (s) (D8:1C) [13:16:31:822]: Skipping action: SetRemovePipCommandLine (condition is false) MSI (s) (D8:1C) [13:16:31:822]: Skipping action: SetUpdatePipCommandLine (condition is false) MSI (s) (D8:1C) [13:16:31:822]: Skipping action: UpdatePip (condition is false) MSI (s) (D8:1C) [13:16:31:822]: Doing action: InstallFinalize MSI (s) (D8:1C) [13:16:31:822]: Note: 1: 2205 2: 3: ActionText Action ended 13:16:31: PublishProduct. Return value 1. Maybe Steve Dower can shed light on why a repair with pip selected didn't try to install pip. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Steve Dower added the comment: Depending on why the pip install failed, we may still have registered that it was installed. IIRC, we only trigger the install on a state change, which wouldn't happen in repair. That deserves its own bug (though maybe this one will suffice if we figure out the original failure - I haven't looked at the logs yet) ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Adrian Chan added the comment: Ah, I'd forgotten about that. When I first tried to run python I got an error complaining about a missing api-ms-win-crt-runtime-l1-1.0.dll I installed the necessary VC redistributable and it solved that problem. So that's why I could successfully ensurepip later on. I'm surprised the manual runtime installation was necessary. Between windows updates and installers for other programs I should already have it installed. Perhaps it got corrupted? That's out of scope for this issue anyway. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29586> _______________________________________
Eryk Sun <eryksun@gmail.com> added the comment: This issue is similar to bpo-25117 in terms of the installer failing to run Python for post-installation tasks. The complication in this case is that a subsequent repair doesn't install pip. ---------- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue29586> _______________________________________
Steve Dower <steve.dower@python.org> added the comment: This was caused by the UCRT not installing properly. These days, the UCRT is installed app-local for Win 8.1, and is already present on Win 10, so it can't happen anymore. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue29586> _______________________________________
participants (3)
-
Adrian Chan -
Eryk Sun
-
Steve Dower