This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients Dima.Tisnek, ned.deily, ronaldoussoren
Date 2019-03-19.04:12:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1552968742.73.0.906244576878.issue36340@roundup.psfhosted.org>
In-reply-to
Content
At first glance, I'm not sure what happened here; we do try to make Install Certificates as bulletproof as possible.  As you probably know, clicking on the file causes it to be opened with the macOS application that Launch Services determines is appropriate.  By default, .command files are associated with Terminal.app (which can be verified by using the Finder's Get Info command on the .command file).  Now apparently you have installed the fish shell (something Apple doesn't ship with macOS) and have changed Terminal.app's preferences or your user account to use fish as the default shell.  The Install Certificates command is a shebang line that should cause it to be executed with the newly-installed Python and that seems to have happened.  But then for some reason, the vendored urllib3 could not be imported correctly.  If you were able to successfully run "Install Certificates.command" from a regular terminal window - without having reinstalled pip - that sounds like some sort of permissions problems which should not happen. Or some other sort of shell startup difference (although the script invokes python with -E to ignore PYTHON* env vars).  Ah, but I now notice you say your normal terminal window is an iTerm2 one.  So, if when double-clicking, the command file runs under Terminal.app but when you run in manually, it's under iTerm2, there *might* be some discrepancy there - I'm not sure what.  One easy thing to try: now that certifi was successfully installed, what happens if you try rerunning the command by double-clicking it?  Does it still fail in the same way?  If so, it would be interesting to get more info on the environment the failing command is running in.  Perhaps the easiest way to do that would be to make a copy of the command file and modify it to do:

    subprocess.check_call([sys.executable,
        "-E", "-s", "-m", "test.pythoninfo"])

just prior to the check_call to install certifi.  As it stands, I'm unable to reproduce the failure with a vanilla macOS system without intentionally modifying permissions etc.
History
Date User Action Args
2019-03-19 04:12:22ned.deilysetrecipients: + ned.deily, ronaldoussoren, Dima.Tisnek
2019-03-19 04:12:22ned.deilysetmessageid: <1552968742.73.0.906244576878.issue36340@roundup.psfhosted.org>
2019-03-19 04:12:22ned.deilylinkissue36340 messages
2019-03-19 04:12:22ned.deilycreate