<div dir="ltr"><div dir="ltr">On Sun, Jun 15, 2025 at 3:49 PM Saj Goonatilleke <<a href="mailto:sg@redu.cx">sg@redu.cx</a>> wrote:<br></div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Sun, 15 Jun 2025, at 06:16, Kenneth Wolcott wrote:<br>
> MacPorts user best practices advice regarding libraries/packages/modules<br>
> <br>
> I'm missing something that must be obvious.<br>
<br>
Not really. :)  As always, I guess the answer is 'it depends'.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.<br>
<br>
There are many Python libraries in MacPorts.<br>
There are even more Python libraries on PyPI.<br>
MP sits downstream of PyPI, so the libraries in MacPorts may be a little 'out of date'.<br>
Which should we use?<br>
<br>
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.<br></blockquote><div><br></div><div>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,  <a href="https://trac.macports.org/ticket/72394">https://trac.macports.org/ticket/72394</a>), virtual environments are a lifesaver. And with the `uv` port (<a href="https://github.com/astral-sh/uv">https://github.com/astral-sh/uv</a>) 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`).</div><div><br></div><div>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`).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> Scenario #1:<br>
> 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?<br>
<br>
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.<br></blockquote><div><br></div><div>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).</div><div><br></div><div>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*).</div><div><br></div><div>-a</div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Austin Ziegler • <a href="mailto:halostatue@gmail.com" target="_blank">halostatue@gmail.com</a> • <a href="mailto:austin@halostatue.ca" target="_blank">austin@halostatue.ca</a><br><a href="http://www.halostatue.ca/" target="_blank">http://www.halostatue.ca/</a> • <a href="http://twitter.com/halostatue" target="_blank">http://twitter.com/halostatue</a></div></div>