MacPorts user best practices advice regarding libraries/packages/modules

[Austin Ziegler]

On Sun, Jun 15, 2025 at 3:49 PM Saj Goonatilleke <sg at redu.cx> wrote:

> 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'.
>

100%. There are different perspectives involved here, and it _very much_
depends on the language/runtime that you're using as well as what you're
using it for.

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.
>

At the same time, if you _do_ need a feature or bug fix that isn't in
MacPorts (and can't be put there easily because it breaks other libraries —
see the issue with prompt_toolkit breaking awscli2,
https://trac.macports.org/ticket/72394), virtual environments are a
lifesaver. And with the `uv` port (https://github.com/astral-sh/uv) or the
`pipx` port, some of these command-line tools become *better* to manage
outside of MacPorts than inside of MacPorts (but I use awscli2 via
MacPorts, mostly because it deliberately isn't in pypi and therefore isn't
available for `pipx` or `uv tool install`).

You're not wrong about the mess that is Python package management and pip,
but that's where `uv` is better and getting better all the time. The
company I work for has a few Python deliverables and ships them with
`uv`-managed venvs (previously, `poetry` was used and not everything has
converted to `uv`).

> 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.
>

Moving from `ruby30` to `ruby33` _should not_ break libraries (Ruby is
*very good* since sometime in Ruby 2.x about allowing side-by-side Ruby
installations _and_ side-by-side Rubygem installations), but you would not
by default have the libraries installed in `ruby30` present in `ruby33`;
you would need to `gem install` those extra libraries. Ruby is a
language/runtime where I think that MacPorts (like _most_ OS-level package
managers) does the wrong thing (mostly because Ruby *explicitly* allows
multiple versions of the same gem to be installed side-by-side, and through
the use of Gemfiles or other venv-like isolation mechanisms, restricted
load), but I don't have a good answer on how to make it better. What I do
know is that MacPorts only recently upgraded from a 10 year old no longer
supported version of mime-types (v1) and is currently sitting on a 18
month-old version (there have been four versions released since then,
including one on May 7) and is also using an 18 month-old data version
(there have been *many* versions as I have a mostly automated release every
week).

I can't speak toward most of the other languages/runtimes, but if you
*cannot* rely only on MacPorts libraries in Python, use a venv. If you
*cannot* rely only on MacPorts libraries in Ruby, use bundler and a Gemfile
(which, while not a venv, is *very very close*).

-a
-- 
Austin Ziegler • halostatue at gmail.com • austin at halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20250615/e3d1ff19/attachment.htm>