MacPorts user best practices advice regarding libraries/packages/modules

[Saj Goonatilleke]

On Sun, 15 Jun 2025, at 06:16, Kenneth Wolcott wrote:
> MacPorts user best practices advice regarding libraries/packages/modules
> 
> I'm missing something that must be obvious.

Not really. :)  As always, I guess the answer is 'it depends'.

I have spent a while thinking about this over the years.  My current view is that we are always going to lose time (productivity); the only thing we can do is choose when to take the hit, and, to a certain extent, how much time we lose in total over the maintenance life of any given system.

I will talk about Python because it is everywhere and is familiar to me.  Much of this is focused on avoiding surprises at run time when using an interpreted lang.

There are many Python libraries in MacPorts.
There are even more Python libraries on PyPI.
MP sits downstream of PyPI, so the libraries in MacPorts may be a little 'out of date'.
Which should we use?

I dunno about you, but I have found pip to be a maintenance nightmare over the long term.  The unix ports systems -- MacPorts included -- 'just work', and have all the features you would expect from a package manager (e.g.: port setrequested).  Stuff keeps working as I update from one OS release to the next.  As someone who tends to write many little programs, and who cannot be bothered with virtualenv-like contortions -- I value this predictability and ease of use.

see also: https://xkcd.com/1987/

So here is the choice:  do we go all-in on the ports system?  Before we can do that, we must promise to avoid any dependencies on fast-moving libraries.  The few library dependencies we may have, in our applications, should either be on the py stdlib or on mature libs with comparable API stability.  Critically, this means we may end up having to write more code ourselves.

This is what I mean in terms of the productivity hit.  Do we front-load the hit, by writing our own minimal stable code from the outset?  This approach will take more time to get to MVP, but we will probably avoid some unpredictable breakage at run time over the next few years.  Or do we 'import move_fast_and_break_things' from pip and save a bit of time upfront?  There is no one correct answer.

At least for py, I can report that it is possible to go (almost) all-in on MacPorts for libs.  All the important stuff is there -- matplotlib, numpy, pandas, psycopg, etc. -- plus some other stuff off the beaten trail.  (The only thing I had not found in MacPorts was one particular optimising constraint solver.  Had to eat a virtualenv there.)  Updates from one Python major release to another are easy.  All the library ports are reinstalled and everything continues to work.

This all assumes that you have a choice.

> Scenario #1:
> When I install a MacPorts port and there aren't any libraries/packages/modules associated with it and I install one or more of the associated libraries/packages/modules from a different source, what are the ramifications when updating/upgrading the MacPort port?

It depends. :)  The Ruby interpreter is available in MacPorts but there are very few Ruby libraries in ports.  The libraries must be installed using some other mechanism.  MacPorts updates to a ruby (interpreter) subport will seldom ever break anything, but moving from the ruby30 to ruby33 subport will probably 'break' all the libraries you had installed elsewhere.

OTOH, other stuff might work fine.  A major update to the Go compiler will invalidate your existing build cache, but all the libraries you had 'installed' outside of MacPorts will remain available for future builds.  (Libraries here are always distributed in source form.)

I wouldn't worry about this too much.  It depends on what you are using, and you will quickly discover what not to do if there is some action to be avoided.

> Scenario #2: The above secnario but when there are libraries/packages/modules associated with the port in question and there are non-MacPorts libraries/packages/modules (from a different source). Same question as above.

If I understand you correctly, this scenario I would usually avoid at all cost.  It is OK to fulfil all of your application dependencies using the ports system.  (But see above with respect to making conscious design choices from the outset.)  It is OK to disregard what is in the ports system and fulfil all of your dependencies using some other mechanism.  But to mix both would probably end in pain.  If nothing else, it may become difficult to determine where the code is coming from.  (Again, it always depends.  It might make sense to vendor the source code for an oddball C library but assume the user will provide libcurl, for example, from MacPorts.)

> I've got this problem with Emacs, Perl, Python and R (perhaps more that I'm not recalling at this point).  I've avoided installing non-MacPorts packages for Scala, OCaml, (others) because I feel certain that I'm going to end up in a weird position (usually without warning) when it comes to updating/upgading MacPorts.

It can help when your language of choice has a sensible package manager of its own.  I would not expect problems with OCaml's Opam.