What is the purpose of MacPorts?

MacPorts is an alternative to Homebrew (unlike Homebrew, it does not mess with the built-in macOS binaries' paths etc and I've had no such trouble with it). I use it to install some command line (and some GUI) binaries like ffmpeg, x265 +highdepth, yt-dlp, tin, mkvtoolnix etc. You need to install Xcode and Xcode Command Line Tools to run it.

"The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac operating system."

https://www.macports.org/

I'll simplify the answer to help add color if you don't know MacPorts, Homebrew, and the like.

(note to the wise: yes, I'm horribly over-simplifying this, but hopefully you get my point).

In the realm of computing over the past 40 years or so (at least outside of the mainframe mindset), the world can roughly be broken into three broad categories:

Windows

Mac

UNIX/Linux *

Windows was everywhere... a closed OS (for the most part), but wide software development support.

Mac was famously closed/proprietary

UNIX was wide open.

Because UNIX could run almost everywhere, on many kinds of computers/processors/etc., much software was distributed in source code form and compiled by the user for their specific machine. This saved the developer from having to maintain distributions for every combination of hardware, and gave the user a lot of control (they could tweak the code to suit their particular needs, subject to licensing terms).

For the first 20 years or so of its life, Mac OS apps were almost exclusively distributed as binary applications that you, the user, could not see or change. You installed it, you ran it, and if it didn't do what you wanted/needed, you looked for an alternative app or made do.

When Mac OS made its transition in the early 2000's to a Mac-style GUI running on top of a UNIX base, that opened up a lot of potential in people's minds that all this UNIX software out there was suddenly going to run on their Mac.

To some degree this was true - you could download some UNIX-based source code and compile it to run on your Mac. However, not all software was written equally... some required esoteric knowledge of how the app works, some required specific libraries or other tangentially-associated code to run. Some needed specific code tweaks to work on a Mac, or to take advantage of Mac-specific hardware.

To the uninitiated, this was a nightmare. Mac users, for the most part, weren't used to dealing with this under-the-hood world that had just been opened.

So a couple of different teams got together to streamline some of this. They took some of the most common/requested UNIX-based apps and did the heavy-lifting to get them to work seamlessly on MacOS - updating the code to take advantage of Mac hardware, tuning compiler flags to optimize the build, etc.

Then they packaged these UNIX-based apps into either binary distributions that you can download and install, or as source code that you can compile locally (if you want that extra degree of headache/control/whatever you call it :) ).

And that's what MacPorts and Homebrew do - they delve into that world of UNIX apps and make it easier for a Mac user to install and use.

For example, say you want to install ImageMagick - a popular UNIX-based tool for manipulating bitmap images... your options are:

Download the source code, tweak/customize it for your machine, build it, fail, install some missing dependency/library (you need libjpg, libtiff, libtool, webp, freetype, and others), rebuild, rinse and repeat until you get a successful build, install it, and run (as well as update it as new versions are released)

- or -

sudo port install ImageMagick7

- or -

brew install imagemagick

and lean on the work that the people at MacPorts or Homebrew have already done.

For the most part they work well, but they're not a panacea... most of the time what you get is a command-line executable that you still drive via Terminal.app, so you're going to need some familiarity with the terminal/command line, but it does at least open that door a crack.

So, if you're looking to run UNIX-based applications on your Mac, and you're not overly familiar with the command line, compiler flags, $PATH dependencies, and the like, then MacPorts or Homebrew is for you.

* yes, I know I'm conflating UNIX and Linux, but for the purposes of this discussion I think that's OK.

MacPorts, Homebrew, and ASDF are simply package and dependency managers for their respectively hosted and installed software. I have never used MacPorts, but I do use Homebrew sparingly for some minor dependency tree apps. I use ASDF for maintaining a current version of Ruby, a programming language that Apple has not updated in macOS for several years.

The keyword here is dependency tree as some applications (e.g. groff, ffmpeg4, imagemagick, graphviz, etc.) have huge ever changing (and growing) dependencies that can change daily. That is a pain in the arse, and why I do not use a package manager to install them.

weeklycod wrote:

""MacPorts"—what is it

I did not understand what it does do , can anybody explain me

I would add that, if you don't understand Matti and Viking's answers, you probably don't need to use MacPorts.

weeklycod wrote:

""MacPorts"—what is it

I did not understand what it does do , can anybody explain me



[Re-Titled by Moderator]

Original Title: ""MacPorts"—what is it

If you don't know what it is or what t does, then how did you come across it?

Are you trying to install something that suggested it?

It's not something you would normally see on a regular Mac install.

Absent any context, I'll second Idris' advice: If you don't know what it is, then you likely don't need it.

Camelot wrote:

When Mac OS made its transition in the early 2000's to a Mac-style GUI running on top of a UNIX base, that opened up a lot of potential in people's minds that all this UNIX software out there was suddenly going to run on their Mac.

To some degree this was true - you could download some UNIX-based source code and compile it to run on your Mac. However, not all software was written equally... some required esoteric knowledge of how the app works, some required specific libraries or other tangentially-associated code to run. Some needed specific code tweaks to work on a Mac, or to take advantage of Mac-specific hardware.

One big example being the graphical user interface.

In old days, many Unix and Linux systems used GUIs constructed on top of MIT's X Window System. These days, I believe that many Linux systems have transitioned to GUIs based on something called Wayland. Mac GUI APIs are not baed either on the X Window System APIs or on the Wayland ones.

Thus, porting GUI software from Linux to macOS requires overcoming the difference in APIs in some way, whether that involves multiple variants of application code, porting libraries that define cross-platform APIs (with the intent of concentrating porting work within the libraries themselves), or running something like an X Window server as a guest application under macOS.

weeklycod wrote:

just testing to achieve nothing, but it added a. plist when I add the package manager

So to answer your earlier question more directly (and yes, slightly flippantly), your attempt to achieve nothing has failed, which means the package manager did not work for your needs.

But again, package managers are a potential means to a goal, and less often is the package manager itself a goal.

Redirecting this slightly, here is a writeup from Julia børk Evans on questions as a topic: https://jvns.ca/blog/good-questions/

I was really bad at technical questions (and at debugging, which is closely related), and it’s taken ongoing practice and thought to be less bad about all of it. But thinking about what I was asking has helped get me to the answers I seek.

And back to the topic of package managers, Homebrew tends to get tangled at times. I’m more recently starting to look at Nix, as it uses a different scheme to keep different versions from getting tangled; seemingly has better dependency handling.

🧐

That's a really great explanation.

> That's a really great explanation.

Thanks - I'd like to think that's closer to the OP's original intent.

Camelot wrote:

> That's a really great explanation.

Thanks - I'd like to think that's closer to the OP's original intent.

I've long since given up trying to guess an OP's original intent.

Will homebrew and Mac ports work?

weeklycod wrote:

Will homebrew and Mac ports work?

Work for what?

Seriously.

What problem or issue or requirement are you trying to solve?

Package managers are a means and not a goal, typically.

just testing to achieve nothing, but it added a. plist when I add the package manager