Tidying up Python

Bill Cole macportsusers-20171215 at billmail.scconsult.com
Fri Jul 11 16:13:02 UTC 2025


On 2025-07-11 at 11:22:39 UTC-0400 (Fri, 11 Jul 2025 16:22:39 +0100)
Lukas Oberhuber <lukaso at gmail.com>
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
  bill at scconsult.com or billcole at apache.org
  (AKA @grumpybozo at toad.social and many *@billmail.scconsult.com 
addresses)
  Not Currently Available For Hire


More information about the macports-users mailing list