Other replies here appear to assume basic compilation issues, but the issues I've seen on various GitHub projects are mostly related to these more insidious C toolchain challenges. They're not M1-specific, but they are manifesting on M1 machines.
https://github.com/pyenv/pyenv/issues/1643#issuecomment-7293...
For installing Python on the M1 Apple Silicon. This will install x86_64 versions, but those will work just fine.
If you're having trouble installing something with brew on M1, run arch x86_64 brew instead of brew to do a Rosetta installation.
My current Mac is going to be my last. Linux on Thinkpad is next
As an example, any time Homebrew ships a new update I run “pipx reinstall-all” and, for local projects, I let pipenv / poetry rebuild the virtualenv the next time I use it. This is automated and takes far less of my time than, say, managing dependency updates.
So, giving up (and re-installing everything from scratch or rebuilding virtualenvs, using several third party tools (pipx on top of pip, pipenv and/or poetry in lieu/in place of virtualenv) is your argument to how "it's not complicated" and people merely "arbitrarily complicate their personal workflows"?
Oh, the irony!
People are trying to fix it, and their are some great packages out there that make it easier. Pyenv, Poetry, this asdf tool the fine article mentions, all seem like good solutions.
So? You can still create nice tools for it, even decades after a language has been created...
I wish more people try out MacPorts.
I honestly put its popularity down to it being written in Ruby, which made it the default choice for the large population of Ruby programmers on the Mac.
I used to use ports back in the days and appreciated it coming from FreeBSD previously but at some point most things I wanted were simply only available in brew, at that time brew and ports didn’t play well together on the same system so sometime around SL/Lion I switched to brew completely.
But "brew" & "homebrew" is just a more charming and hipster name for a newbie to write in his blog for other newbies to follow, repeat eleventy-seven-hundred times.
I also never understood the concerns about correctness. Very few people want homebrew to be an apt/rpm replacement for servers that will provide stability for decades. Most Macs are effectively single-user systems, and if something goes wrong then nuking the whole homebrew directory and starting over is not a big deal.
I agree that we could definitely improve our documentation on what people can and should expect from a Homebrewed version of Python; I'll look into opening a PR that improves these docs tonight.
The decision to remove build options was informed (in part) by user experience: for every one user who was using them correctly to configure a package slightly differently for their uses, there were fifteen users following outdated SO answers and reporting their own breakages to us. Like every other package manager that distributes binary builds, we made a decision to improve the 99% use case.
https://github.com/pyenv/pyenv
What's nice is you can find analog programs for a lot of different languages and platforms including
Node: https://github.com/ekalinin/nodeenv
Ruby: https://github.com/rbenv/rbenv
Terraform: https://github.com/tfutils/tfenv> 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.
If you want to develop Python (likely Ruby/ PHP/ 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/ rpm/ etc).
Homebrew's guarantees are no different from those of apt or any other system package manager; the only difference is that we don't have a stable distribution version to lock our Python or Ruby versions against. Individual developers will always be best served to isolate their development environments from the overarching runtime environment that's been distributed to them.
For others similarly curious, it appears setting [`$HOMEBREW_NO_AUTO_UPDATE=1`](https://github.com/Homebrew/brew/blob/2.7.7/docs/Manpage.md#...) is the magic sauce (or the perhaps more accurate link: https://github.com/Homebrew/brew/blob/2.7.7/Library/Homebrew... )
At the end of the day, they're people volunteering their time for little to no benefit. Of course they should put themselves above their users; their users aren't even paying them for said time.
When you switch from Mac/Windows to Linux, you think "wow, this OS was actually made for software development. Everything just works. I don't have to resolve a library version conflict every 3 days."
If you can live with the rough edges, I find the general experience with applications or my printer suddenly being incompatible under MacOS for "reasons" is much less of an issue under Linux.
In my experience they work great, you can install multiple versions, and even pip3 seems to just work with them.
I'm not a heavy Python user, but ever since I started using the official installers it just works.
I could be mistaken, but I didn't find any documentation on how to do it and the fact that other people had projects to try and do it mean that I wasnt alone on finding this a bit of a mess.
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'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?
I would be grateful for any guidance.
Otherwise if you're trying to use some python project with particular dependencies pyenv is a good way to get a specific python version. But if the project has a lot of native dependencies (think scientific computing with lots of fortran, C++, etc. code to compile) then you're almost certainly better off with conda as a higher-level entire binary system manager.
For managing virtual environments on my preferred shell (Fish), I use (and maintain) VirtualFish [2].
For managing project dependencies, I activate environments via VirtualFish and then use Poetry [3] to update the dependencies within the environments.
[1]: https://github.com/danhper/asdf-python
Similarly I'm sure that making `brew install X` implicitly perform `brew upgrade` simplifies things a lot for them, but it's been a major source of hassle for me and it's making me consider switching away from homebrew.
I can't tell if that would influence the behavior you're experiencing, but it sounds like it makes the brew command more deterministic
Python does not explicitly set this to what it wants (off), so if you didn't happen to have "set enable-bracketed-paste off" in your ~/.inputrc, pasting got messed up.
This isn't just a Homebrew thing. It also hit Arch Linux, and probably others.
As part of trying to figure out who to file a bug report with, I installed Apple'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).
The python.org Python3 was easy to install, and was the same version the Homebrew installed.
This raises a question. The article talks about alternate systems to manage Python installations instead of using Homebrew or using Apple'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?
Also, when using pyenv, I almost always set `env PYTHON_CONFIGURE_OPTS="--enable-framework" pyenv install -v ${pylatest}` (macOS) or `env PYTHON_CONFIGURE_OPTS="--enable-shared" pyenv install -v ${pylatest}` (Linux). (I also set some CFLAGS, but these are personal preference.) I've had plenty of situations where not having the shared/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've never had issues where the shared build screwed something up.
[1]: https://asdf-vm.com/
I really like Homebrew but its dependency management is horrible. The moment I saw that dyld "image not found" error message I didn't even have to finish reading the article to know what happened.
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.
Granted, I've only lived in these tools just long enough to install what I need, so I'm sure I'm naively overlooking a lot of nuance.
Sort of analogous to the way the JVM is distributed usually as separate packages with the JRE and the JDK.
I don't write very much prod-grade Python, so I just recreate the venv with my requirements.txt instead.
I have successfully confused people who sought meaning in 'asdf' when the string is absolutely meaningless, actually being the left-hand home keys.
'asdf' could be interpreted as "totally blew off that 'naming' thing".