[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:  enhancement  |     Status:  new
  Priority:  Low          |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  libpsl       |
--------------------------+--------------------
Changes (by ryandesign):

 * type:  request => enhancement


Old description:

> 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.

New description:

 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?
      wiki:FAQ#syslibs
    * "Why is MacPorts using its own libraries?"
      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.

--

Comment:

 Using the system's python is acceptable and a good idea if external
 modules that aren't shipped with the system are not required. Many ports
 already do this.

 Unconditionally using /usr/bin/python3 will break macOS 10.14 and earlier
 which don't have that. They do have /usr/bin/python however. The port
 could choose which one to use based on the OS version. See other ports
 that already do this.

 I didn't find your PR but when you make it you can add a URL to it here.

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