I use MacPorts. It has a slightly smaller selection of software, but I it doesn’t rely on any Apple-installed software, and also it requires an administrator user to install packages.
Edit: While it’s clear that MacPorts’ package list is much larger than Homebrew’s, it’s not clear which of them offers more packages (or how many more) because MacPorts supports multiple versions of its packages while Homebrew does not. Either of them probably have what you want.
Hm. Sounds like the installed software could run with admin privileges then?
I prefer installing in user land, if possible.
ICYMI, for those who are afraid of terminal, Cakebrew is an alternative to Homebrew. It’s Hombrew GUI where you can handle usual tasks conveniently.
Well, any software could run with admin privileges (or try to). The reason I prefer using sudo is that it helps avoid collisions with other user-installed software, as does installing software in its own location rather than /usr/local.
Really, the question of homebrew vs. macports is a matter of personal taste, they both do essentially the same thing.
Perhaps related, you’ve mentioned that you run Docker. Could you explain why you’re using it, and how?
What I like in homebrew is ability to create list of currently installed brews (command line applications), casks (GUI applications) and mas apps via brew-bundle. Then I can take this file and re-install the same set of applications on another mac.
Hi @jec0047. I am going to nuke and pave my Mac soon and was intrigued by your comment to checkout MacPorts. After some further research (mainly Saagar Jha’s excellent article and the discussion about it) I am thinking of using MacPorts instead of Homebrew.
I am a noob when it comes to scripting etc. but am able to find my way around the few packages that I rely on. I would be very grateful if you could expand on how it is that you have Python set up on your system. I remember having to jump through a lot of hoops when Python 2 reached EOL and having to symlink things etc., which I gather is not the best idea.
My main questions are:
- Is installing Python on MacPorts as simple as running
sudo port install python37?
- I take it that ports can be updated via
sudo port upgrade outdated but will this upgrade Python 3.7 to 3.8/further versions when they are released? (As an aside, I see that Python is at version 3.8 but has not even been updated on Homebrew because of some issues )
- How do I ensure that packages/scripts that need Python 3 have access to it without making changes to the macOS Python as per @rms’s advice on another thread?
- Does using Miniconda/Anaconda fit into this (specifically point 3?) I must confess that I know even less about pip/virtual environments than I do about everything I have mentioned so far! It looks like Anaconda would need me to install packages from Conda and so it replaces MacPorts instead of working with it. Would this be correct?
This is a lot to ask so please feel free to ignore bits of it. Thank you!
I’ll do my best to answer, however 1) I don’t have access to my Mac right now, and 2) I don’t use Python, so you may have to validate what I say.
I assume you know that MacPorts requires Xcode’s command line tools, which are free from Apple. You don’t need the full-blown XCode development environment.
Q: Is installing Python on MacPorts as simple as running
sudo port install python37 ?
Q: I take it that ports can be updated via
sudo port upgrade outdated
Q: will this upgrade Python 3.7 to 3.8/further versions
A: I’m not sure, but I would guess not. However, if you ‘sudo install python3’ (instead of python37) I would guess that it would upgrade in the manner you describe.
Q: How do I ensure that packages/scripts that need Python 3 have access to it without making changes to the macOS Python
A: When you install a “port” (a package), the port will specify what it needs and MacPorts will install it automatically. MacPorts installs everything in a dedicated directory structure, and it will install everything except software that is included in the XCode command line tools. Python is not part of XCode so MacPorts will install it (if needed). Presently, that means you would have multiple installations of Python (the one Apple includes, and the one you install with MacPorts). The ports are built to use MacPort’s installation of Python.
Q: Does using Miniconda/Anaconda fit into this (specifically point 3?) It looks like Anaconda would need me to install packages from Conda and so it replaces MacPorts instead of working with it. Would this be correct?
A: From a cursory glance at their website it appears you are correct. I don’t know how installing multiple package managers would work out but it doesn’t seem like a good idea to me.
Edit: Thanks for the link @Ajay, it explains the differences between MacPorts and Homebrew very well.
I also prefer MacPorts. Since I like to use the terminal a lot, having tons of amaziong packages just an “install” away, is great.
Well, I had a nice long answer typed up and lost it somehow.
Anywho, your life will be much happier, including fluffy kittens and green meadows, if you install Anaconda and use conda. Conda manages packages for your Python install, and creates and manages environments. These environments can be set up with different versions of python, packages, etc. You can further switch between them, thus having them set up for different projects. It does this by changing the environment variables, paths, symlinks, etc.
With Anaconda, you also get Anaconda Navigator which can manage packages, environments, and applications like PyCharm, which is a nice IDE for python development.
I recommend you install iTerm2, which can change the prompt to reflect the conda environment (as well as git branches, etc.).
So you use Anaconda and Homebrew?
BTW, I’m glad you chimed in here because, as I said, I don’t use Python, and I know you do.
Yes, they serve different purposes.
I use conda for python-specific things, and homebrew for non-python.
Lol. I was careful to give you first crack at it.
@Ajay might be interested in these free Python books.
I originally used MacPorts for package management on MacOS, but switched to Homebrew for two reasons (many years ago):
- The bloat caused by not re-using dependencies / not using built-in libs by MacPorts was extensive. I remember it being many GB of wasted space on my first Macbook, which only had a 128GB HD so the space was precious.
- Homebrew packages were updated far, far more frequently. MacPorts had many more packages available, but many of them were out of date. When it came to packages I actually wanted to install, Homebrew invariably had the most current version, whereas MacPorts often did not.
Admittedly, I made the switch to
brew many years ago and haven’t revisited this decision since then, but that was my reasoning back then.
Something else I like about Homebrew is the
brew cask command, which allows you to very easily install GUI applications from the command line as well. I just bought a new MBP, and setup of my fairly involved system was pretty easy with Homebrew. All the dev type stuff I installed with normal
brew, and the vast majority of my favorite GUI apps are available as casks, as simple as
brew cask install chrome. I just have a list of the casks I want to install that I feed to the command, and boom, I’m setup with my GUI apps.
Homebrew supports multiple versions, and even supports multiple versions being installed, and switching between them. https://stackoverflow.com/questions/3987683/homebrew-install-specific-version-of-formula#4158763
Homebrew also has the
brew doctor command for checking out the installed packages and system for possible problems.
My experience with Fink and MacPorts was similar to @acnebs, and in addition to the bloat, at some point they both just made a mess of things. Admittedly that was several years ago. After installing homebrew, that hasn’t happened, and it’s worked really well for me.
Thank you all very much for your thoughtful and detailed responses.
@jec0047, looking back I think I should have framed point 3 better! It looks like packages installed with MacPorts will access the MacPorts installed version of Python without any trouble. However, I do use some simple scripts that call on Python and it is these that broke for a while when Python 2 reached EOL. Do I need to/would you guys recommend doing something like
sudo port select --set python python35 and/or
sudo port select --set python3 python35 to make sure that scripts have access to the MacPorts Python or would this qualify as tinkering with the macOS Python and hence not be advisable?
@JohnAtl, thanks for recommending the books and for your recommendations. I confess that much of it is beyond me at the moment! I am able to run the few, basic scripts and packages that I use (qpdf, youtube-dl etc.) and my needs aren’t greater than that at the moment and so, from a cursory look a few days ago, I felt that Anaconda might be an overkill. I must check out those books to learn more!
Your second point first: This makes perfect sense and I would have done the same thing with the small HDD.
As to the first point, a lot of those built-in libs (and whole applications) are going to be disappearing at some point, when Apple stops distributing them with macOS.
Yes, I think you would want to do ‘sudo port select…’. No, that will not tinker with the built-in versions. Note, however, that if the scripts you are using name a specific binary (e.g. ‘/usr/bin/python …’), which is quite likely, then that binary will be used. To correct that, you will have to modify the scripts.
Right, so the scripts I am looking at call /usr/bin/env python What would I have to do in this case?
These scripts are downloaded from GitHub and apparently I am not supposed to change anything inside or else they don’t auto-update if I understand correctly
Is there anything else that I should do? I think I did run
ln -sf /usr/bin/python2.7 /usr/bin/python when I had done the initial setup. Apologies if I am asking very basic questions!
After installing MacPorts and doing the ‘sudo port select …’, ‘/usr/bin/env python’ should give you the right binary. What you need to look out for are references to /usr/bin/python.