Stop looking for Homebrew openssl?

[brandonfriess-stripe]

I'm curious if this project would have any interest in moving away from using openssl from homebrew by default? Similar to what ruby-build has already done.

While the dynamic linking to brew installed openssl versions at brew --prefix openssl@1.1 is nice, it will eventually break python installs whenever openssl bumps their formula version and a user brew upgrades it (or another package that declares a dependency on openssl updates it).

It appears like most of the code in python-build would support this change pretty easily. I replicated the changes from the ruby-build PR linked above and was able to install python versions successfully. Admittedly, I haven't tested this extensively.

Thoughts?

[tomy0000000]

I've recently also encountered an simlilar issue when homebrew bumped OpenSSL to version 1.1, the old pyenv-compiled python failed to resolve the correct path.

For those who came across to this problem, you need to reinstall all compiled python with pyenv which build a new python with the correct openssl path.

However, I think using homebrew OpenSSL is still a good idea, reasons as follow:

• You shouldn't be using system OpenSSL, as you wouldn't use system builtin Python, either.
• Managing a correct version of OpenSSL is probably beyond the scope of pyenv.

A good way to prevent link breaks from homebrew upgrading is to bind to a correct directory.

$ brew --prefix openssl@1.1
/usr/local/opt/openssl@1.1
$ readlink /usr/local/opt/openssl@1.1
../Cellar/openssl@1.1/1.1.1g

If you look deeper, you'll find

$ ls -l /usr/local/opt | grep openssl
lrwxr-xr-x  1 tomy0000000  admin  28  9  8 00:09 openssl -> ../Cellar/openssl@1.1/1.1.1g
lrwxr-xr-x  1 tomy0000000  admin  28  9  8 00:09 openssl@1.1 -> ../Cellar/openssl@1.1/1.1.1g

Therefore, a possible solution might be

1. Use exists method to verify that homebrew has installed openssl, openssl@1.1, or any future release
2. Use /usr/local/opt/openssl as OpenSSL path to build python

This method guaranteed that whenever there's a new version of OpenSSL, as long as homebrew point the symlink to the latest version, the old python is able to resolve with that symlink.

[brandonfriess-stripe]

I think it's problematic using Homebrew openssl for a few reasons (the below is taken from ruby-build):

• The user may have an incompatible version installed
• The user may not know that a particular version of openssl has been installed by Homebrew
• The openssl version split now makes this logic more difficult to maintain for all versions of python that python-build can install

In general, it's really toilsome to have to re-install all your Pythons because you updated a Homebrew package that in turn updated your openssl version.

You shouldn't be using system OpenSSL, as you wouldn't use system builtin Python, either.

Managing a correct version of OpenSSL is probably beyond the scope of pyenv.

As far as I can see, python-build already specifies an openssl version needed for each Python version (ex: here), so I think most of those concerns are negated?

For those that wanted to compile against Homebrew openssl, they could likely do something like PYTHON_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@1.1)" pyenv install 3.8.5

[native-api]

• This would mean that we'll have to supply our own copy of OpenSSL for each Python installation -- and thus

  • lose free upgrades. For a library responsible for Internet security of our software, that's a BIG drawback.
  • have a zoo of different OpenSSLs on the system and their corresponding certificate stores
    • which can't even sync with MacOS keychain store unlike the Homebrew one, leading to the headache of certificate errors for users.

• This looks like just a residue of Homebrew migrating to a new major version of OpenSSL.

  • This is a rare event (1.0.x has been around for 5+ years and 0.9.x before it for 17(!)), and a migration to an new major (=incompatible) release always involves old software being left behind since it's now incompatible and unmaintained. There's no way around it.
  • Moreover, Homebrew have learned their lesson and made the new formula versioned (openssl@1.1) -- so you can even install "openssl@1.0" alongside it from somewhere and link Python against it if you want -- and so you'll be able to do on the next migration whenever it happens.

To summarize, the pros of using OpenSSL from Homebrew still majorly outweigh the cons AFAICS.

[joshfriend]

A friend of mine wrote a pyenv plugin that can attempt to relink libraries like openssl after they get moved by homebrew: https://github.com/sprout42/pyenv-fix-version

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.