Changes to Homebrew adversely affect Python development

Use Homebrew to install pyenv and pyenv-virtualenv. Then use those to install pythons and collections of packages. You'll have stable development environments.

Ran into this myself. Starting using `pyenv` instead. Never looked back. Allows you to maintain multiple versions of python outside brew&#x27;s control and the system&#x27;s.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;pyenv&#x2F;pyenv" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pyenv&#x2F;pyenv</a><p>What&#x27;s nice is you can find analog programs for a lot of different languages and platforms including<p><pre><code> Node: https:&#x2F;&#x2F;github.com&#x2F;ekalinin&#x2F;nodeenv Ruby: https:&#x2F;&#x2F;github.com&#x2F;rbenv&#x2F;rbenv Terraform: https:&#x2F;&#x2F;github.com&#x2F;tfutils&#x2F;tfenv</code></pre>

Article author here. I think my biggest complaint is that there’s no disclaimer on the box [1]. Homebrew folks <i>know</i> about these problems, but they don’t warn users that their virtual environments will be obliterated. If Homebrew explained that these problems can happen, and that developers might want to use a different source for installing Python interpreters, my ire would be lessened considerably.<p>[1] <a href="https:&#x2F;&#x2F;docs.brew.sh&#x2F;Homebrew-and-Python.html" rel="nofollow">https:&#x2F;&#x2F;docs.brew.sh&#x2F;Homebrew-and-Python.html</a>

MacPorts is installing Python just fine here, fwiw. There&#x27;s a package for each Python 3.x version so you can have whatever random versions you need installed. They can be used in virtualenvs easily and they don&#x27;t break when you have to install an update for a 3.x.y release.

I know this is frustrating, and I expect it affects more than just Python developers, but I think the author sums it up pretty well here:<p>&gt; Homebrew’s Python is not for you. It exists to serve Homebrew, or more accurately, Homebrew’s other formulae. The primary purpose of Homebrew’s Python formula is to enable other Python-dependent Homebrew packages to work.<p>If you want to develop Python (likely Ruby&#x2F; PHP&#x2F; whatever), you are best keeping your dev environment separate from the interpreters installed for the purpose of running apps managed by Home-brew (or apt&#x2F; rpm&#x2F; etc).

A postgres update seriously fucked up my work Ruby install as well. We were using an old version and homebrew updated openssl on us (from 1.0.1 to 1.1 I think?) with no way of going back. (The Ruby install I was running was linked to 1.0.1, so it was not happy with having its library deleted.) I spent a month trying to figure out how to get that shit working again.<p>I really like Homebrew but its dependency management is horrible. The moment I saw that dyld &quot;image not found&quot; error message I didn&#x27;t even have to finish reading the article to know what happened.

Homebrew Python recently had a problem with pasting in the REPL, because it uses GNU Readline and Homebrew recently updated that from 8.0 to 8.1. GNU Readline changed the default for bracketed paste mode from off in 8.0 to on in 8.1.<p>Python does not explicitly set this to what it wants (off), so if you didn&#x27;t happen to have &quot;set enable-bracketed-paste off&quot; in your ~&#x2F;.inputrc, pasting got messed up.<p>This isn&#x27;t just a Homebrew thing. It also hit Arch Linux, and probably others.<p>As part of trying to figure out who to file a bug report with, I installed Apple&#x27;s Python3 and I installed the Mac version of Python3 from python.org. It worked fine in the later two, so I filed the bug with Homebrew [1] (and they figured out that it is really a Python bug and they submitted a pull request upstream to have Python explicitly turn off bracketed paste).<p>The python.org Python3 was easy to install, and was the same version the Homebrew installed.<p>This raises a question. The article talks about alternate systems to manage Python installations instead of using Homebrew or using Apple&#x27;s Python. But why do I want any of them? The python.org install seemed fine. Why not just use that and not have to deal with any third party Python installation managers?<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;Homebrew&#x2F;homebrew-core&#x2F;issues&#x2F;68193" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Homebrew&#x2F;homebrew-core&#x2F;issues&#x2F;68193</a>

You should give MacPorts a try...<p>MacPorts allows you to install multiple Python versions at the same time and I personally have several venvs with Python 2.7, 3.6, 3.7, 3.8, 3.9... all running without a glitch.

This was one of the pain points that made me move back to Linux on my devices, and I&#x27;m glad I did it. Homebrew is infuriating when you&#x27;re used to real package managers.

I&#x27;d be perfectly happy with homebrew if it didn&#x27;t auto-update all packages when installing something new. E.g. I do `brew install ffmpeg`, and as part of that it upgrades python from 3.8 to 3.9 (???), breaking imports in all my scripts. I know how to work around this, but still, surprising choice for the default behavior.

I&#x27;m a little surprised more people aren&#x27;t using `anyenv`. That lets you install &amp; update pyenv, nodenv, rbenv, etc. (though some support for certain languages is spotty) and thus get everything built&#x2F;installed the way you want it.<p>Also, when using pyenv, I almost always set `env PYTHON_CONFIGURE_OPTS=&quot;--enable-framework&quot; pyenv install -v ${pylatest}` (macOS) or `env PYTHON_CONFIGURE_OPTS=&quot;--enable-shared&quot; pyenv install -v ${pylatest}` (Linux). (I also set some CFLAGS, but these are personal preference.) I&#x27;ve had plenty of situations where not having the shared&#x2F;framework build has screwed something up (and in fact that was my original reason for switching from Homebrew or package manager-installed Python years ago), and I&#x27;ve never had issues where the shared build screwed something up.

Can someone explain why nobody seems to use the official Python installers from python.org?<p>In my experience they work great, you can install multiple versions, and even pip3 seems to just work with them.<p>I&#x27;m not a heavy Python user, but ever since I started using the official installers it just works.

Where my conda crew at?

I believe I have noticed this as well with Ruby as well. All Gems work great, then, after a brew operation, I need to reinstall&#x2F;rebuild against an updated Ruby. It&#x27;s certainly frustrating and can bite you, especially since it is unexpected.

I have had good experiences with Conda [1], and generally use Miniconda.<p>[1] <a href="https:&#x2F;&#x2F;docs.conda.io&#x2F;en&#x2F;latest&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.conda.io&#x2F;en&#x2F;latest&#x2F;</a>

I totally get that package management is Hard. However, I feel like Homebrew should be able to track what&#x27;s there because it&#x27;s a dependency vs what&#x27;s there because the user wants it to be and act accordingly.<p>Granted, I&#x27;ve only lived in these tools just long enough to install what I need, so I&#x27;m sure I&#x27;m naively overlooking a lot of nuance.

Ah interesting. It appears that the reason for this difference is that Python on Homebrew is delivered as a single package for development and execution. The true intention should have been to have had Python-Homebrew to create the environment for Homebrew and Python-Dev which you can use for your development.<p>Sort of analogous to the way the JVM is distributed usually as separate packages with the JRE and the JDK.<p>I don&#x27;t write very much prod-grade Python, so I just recreate the venv with my requirements.txt instead.

As someone who doesn&#x27;t often use Python what is the current &quot;best&quot; solution for installing and managing your environment?<p>Last time I used Python on macOS and Windows I manually installed the official version from python.org and used pip and virtualenv. It wasn&#x27;t too bad but it seems things have changed in the last 6 years or so? Or is this still the most flexible way to go?<p>I would be grateful for any guidance.

Homebrew and its excellent community was once indispensible on the Mac, but various pain points including this flakiness made me switch to (mini)conda for nearly everything, despite initial apprehension. There are some wrinkles and the resolver is slow, but in my hands conda is just so much more reliable than Homebrew ever was.

I loved Homebrew, but it really seems to have gone to shit the last couple years. Are they spreading themselves too thin?

Relevant xkcd:<p><a href="https:&#x2F;&#x2F;xkcd.com&#x2F;1987&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;1987&#x2F;</a>

I gave up and just started using the OSX system copy (along w&#x2F; Google Colab), the main reason being that nearly every time there was a system update something would break and I would have to pin&#x2F;unpin python@3.x

So many different ways to install Python - doesn’t anybody just use the official installer from python.org&#x2F;downloads?

&gt;<a href="https:&#x2F;&#x2F;asdf-vm.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;asdf-vm.com&#x2F;</a><p>I have successfully confused people who sought meaning in &#x27;asdf&#x27; when the string is absolutely meaningless, actually being the left-hand home keys.<p>&#x27;asdf&#x27; could be interpreted as &quot;totally blew off that &#x27;naming&#x27; thing&quot;.

I will almost resist the urge to truncate the title to &quot;Python is Not for You&quot; -- but I&#x27;d like to second the benefits of using a python version manager such as pyenv. Yes, all the versions waste an ungodly amount of space, but you probably can&#x27;t&#x2F;won&#x27;t use Clojure instead I guess.

I gave up on Homebrew for Python development and now use Conda. Never looked back.

Why does everything related to versioning and packaging have to be so difficult with Python? I never understood that.

This all stems from the official policy of only caring about themselves and putting themselves above the users. <a href="https:&#x2F;&#x2F;docs.brew.sh&#x2F;Maintainers-Avoiding-Burnout#3-prioritise-maintainers-over-users" rel="nofollow">https:&#x2F;&#x2F;docs.brew.sh&#x2F;Maintainers-Avoiding-Burnout#3-prioriti...</a>