On Sun, Jun 15, 2025 at 3:49 PM Saj Goonatilleke <[email protected]> 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 • [email protected] • [email protected] http://www.halostatue.ca/ • http://twitter.com/halostatue
