On 2025-07-11 at 11:22:39 UTC-0400 (Fri, 11 Jul 2025 16:22:39 +0100)
Lukas Oberhuber <[email protected]>
is rumored to have said:
This may be well off topic, but I strongly suspect the expectation for
others (and it certainly applies to me) is that all of the packages
who
need it, depend on one singular python release.
That expectation cannot be met by a 'ports' project in the real world
for Python, Perl, Ruby, PHP, or any other language with a rich bazaar of
independently-developed packages.
And that when that default
release is changed, all the packages depend on the new release, even
if
they were installed previously.
Unfortunately, each release can break existing packages. Sometimes you
have a package in Python that depends on a 3rd-party non-Python tool
(e.g. LLVM) which in turn has its own internal dependency on Python
which may be version-specific.
The current situation where every package decides on its own which
python 3
version to support, feels wrong to me. How often does a different
package
truly need an exact python version, and if it does, maybe that can be
handled separately?
MacPorts is not the place for fixing this deep problem. The problem is
in the Python culture of every Python program dragging around its own
bespoke development world.
I don't know if this is a core limitation of macports, since the same
happens for llvm, gcc, clang and other tools.
It's a core limitation of every FOSS package manager. It is intrinsic to
the FOSS world. There is no top-down authority.
I've just had a round of cleaning up packages on some FreeBSD systems I
administer. Their ports and packages subsystem is probably the most
mature one in existence handling the FOSS world. They have a pretty good
model for handling this problem but still: on multiple machines I had to
leave a Python 3.9 world in place alongside a due to one or more
dependency chains where an upstream has yet to validate their code as
working on newer versions. There is no 3.13 port yet, presumably because
not enough software demands it.
I'm really not keen on the current state: having to install (and in my
case, build) a broad swathe of the history of software development
tools in
order to get the suite of packages I need.
I checked my ci build directory and it is currently 49GB.
My context: I package GIMP's official release and have to build
*everything* because I compile/link to older SDKs.
I can only offer my deepest condolences.
--
Bill Cole
[email protected] or [email protected]
(AKA @[email protected] and many *@billmail.scconsult.com
addresses)
Not Currently Available For Hire
