[MacPorts] #72036: libpsl: Avoid Python dependency by using system python3

[MacPorts]

#72036: libpsl: Avoid Python dependency by using system python3
---------------------+--------------------
 Reporter:  ferdnyc  |      Owner:  (none)
     Type:  request  |     Status:  new
 Priority:  Low      |  Milestone:
Component:  ports    |    Version:
 Keywords:           |       Port:  libpsl
---------------------+--------------------
 I have a (perhaps) radical suggestion for libpsl, specifically, and how
 the clang_dependency morass can be eased some.

 First off:

 1. I have read the comments in the file, and I understand why the Python
 dependency there is so carefully managed and fragile.

 2. I have read tickets [70998], [55509], [60419], and others, so I know
 the history on this.

 3. I have read these FAQ entries:
    * "Will MacPorts link to system libraries rather than its own?
      https://trac.macports.org/wiki/FAQ#syslibs
    * "Why is MacPorts using its own libraries?"
      https://trac.macports.org/wiki/FAQ#ownlibs

 4. Because I have read those FAQ entries (and because I've been doing this
 stuff for a long time), I understand the importance, under normal
 circumstances, of dogfooding and of self-contained software collections.

 All the above notwithstanding, I ''also'' understand the importance of
 managing versions across package sets, and of avoiding dependency circuits
 and managing cascading dependency trees that can lead to conflicts and
 failures.

 == The libpsl Python dependency

 libpsl has a Python dependency for ONE reason and ONE reason only: It both
 runs (during the build), and provides to the user, the script that will
 ultimately become `${prefix}/bin/psl-make-dafsa`.

 This script is the most bare-bones of Python code possible: It contains
 three imports, all from the standard library (`sys`, `os.path`, and
 `hashlib`), and it is compatible with every Python version going all the
 way back to Python 2.7. It can easily be run, reliably, with the
 `/usr/bin/python3` present in every version of macOS for at least the past
 5 years.

 And that script is the sum total of libpsl's Python needs. It neither uses
 nor installs any Python modules beyond the standard library, it very
 explicitly AVOIDS any syntax that would exclude older Python versions, and
 it would not be expected to present any compatibility headaches should
 Apple either change their system Python3 version, or somehow manage to
 screw it up in some obscure fashion. (In the incredibly unlikely event
 that should occur, well, that's a bridge that can be crossed if it's ever
 encountered.)

 == The Python requirement for `psl-make-dafsa`

 Unlike Python packages/modules or the ports that make use of them, simple
 python-stdlib-only scripts ''really are'' independent of and agnostic to
 the specific python version they're run with. But since macports can't
 express that sort of dependency currently, eliminating it where possible
 is the next best solution. If ever there was a time to take advantage of
 system resources, this would seem to be that time.

 Removing libpsl's versioned python dependency means you can get all the
 way to installing curl without incurring any Python dependency, which
 helps prune the dependency graph somewhat for all of its dependents,
 including cmake. Which only makes the maintenance of all of those other
 packages that much simpler going forward, as there are fewer packages to
 juggle trying to keep versions in sync.

 == The proposal

 That's it, right there: Just eliminate the Python dependency in the libpsl
 `Portfile` entirely. Instead of the current code that modifies `psl-make-
 dafsa` so that the shebang is `#!/opt/local/bin/python${py_ver_nodot}`,
 instead set it to `#!/usr/bin/python3`, and also pass `/usr/bin/python3`
 to the configure as its `python` argument.

 I'd have just opened a PR in the repo with that change to the libpsl
 `Portfile`, but I felt that might come off as presumptuous so I figured
 I'd open this ticket for discussion first. If the response is, "Not just
 no, but HELL NO!" then I'll leave it at that.

-- 
Ticket URL: <https://trac.macports.org/ticket/72036>
MacPorts <https://www.macports.org/>
Ports system for macOS