I think some HTTP libraries may (optionally) use `pyopenssl` instead of PSL `ssl`. (Pretty sure `requests[security]` does this.) Maybe `pyopenssl` is capable of picking up the correct OpenSSL at runtime, or your `pyopenssl` was installed/upgraded post OpenSSL upgrade so it was linked against the correct dylib.
I didn't bother to check any actual code so the above is pure speculation.
Anyway, we have a no-third-party-dep policy so we can't do anything like that. A Python with borked `_ssl` is crippled in my book for all intents and purposes.
That's been discussed before many times. We explicitly disallowed any dependencies, so restructuring the repo just for installing a single script with pip is pointless. It also won't avoid a broken Python problem, so not sure how that's related.
Updating OpenSSL is usually fine, the jump from `libssl.1.0.0.dylib` to `libssl.1.1.dylib` is extremely rare. The dylib version number 1.0.0 has been the same for years. However, when it does change and you remove the old one, everything that depends on it *will* break (Homebrew can do its best making sure its packages are all recompiled, but it can't do anything about your pyenv Python installs).
This is not unique to OpenSSL either, just the nature of dynamic linking. If one day `libsqlite3.0.dylib` becomes `libsqlite4.0.dylib`, your old Python installs will break too.
Dude, that's an `HTTPConnection`, not `HTTPSConnection`. Trust me, as a former Homebrew maintainer I can spot a Homebrew problem from miles away, so just recompile.
Chill, I was typing ;)
From the linkage here
```
Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
```
it means when you compiled this Python 3.5.4 with pyenv you had OpenSSL 1.0.x installed with Homebrew, but later the `openssl` formula, at least `[email protected]`, was uninstalled. You probably either have no `openssl` now or only have `[email protected]`. Either way, `brew install openssl` to make sure, then recompile Python with pyenv.