[MacPorts] #68137: PortGroup for ports requiring Python that can't use the Python build system

[MacPorts]

#68137: PortGroup for ports requiring Python that can't use the Python build system
----------------------+--------------------
  Reporter:  RJVB     |      Owner:  (none)
      Type:  request  |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:
Resolution:           |   Keywords:
      Port:           |
----------------------+--------------------

Comment (by ryandesign):

 Replying to [ticket:68137 RJVB]:
 > It'd be much more efficient if those definitions and whatever other
 common code there is were available via a PortGroup, one that would
 probably also be included by the current Python PG.

 Each port still needs to communicate that information to the build system
 in a way that the build system understands. Some use the PYTHON
 environment variable at configure time. Some use a configure script that
 takes a flag like `--with-python=/path/to/python`. Some use cmake or meson
 which use arguments like `-DPYTHON_EXECUTABLE=/path/to/python` or
 `-DPYTHON_EXEC=/path/to/python` or `-Dpython=/path/to/python`. Some need
 the python path inserted into various source files (e.g. in `#!` lines)
 with `reinplace`. Some need to be told the library and include paths
 separately. So there is no generic one-size-fits-all solution that could
 be put into a portgroup and it's not that hard for ports to construct the
 necessary paths.

 > In addition I would like to see some feature in that new PG for ports
 that just require ''**a**'' Python interpreter for their build. Now that
 Python 2 seems to be in the process of being dropped more and more for
 this purpose it would be ideal if there were a "system" python3 port for
 that purpose. Most users probably don't have a need for having multiple
 python3 installs and every interest to have only a single such install
 that gets updated as required.

 There has never been an intention to offer a "system" python3 port. It
 would directly conflict with the `port select` mechanism.

 > In my `port:audacity` this build dependency is handled implicitly
 through the build (and fetch) dependency on `port:git`. Not ideal, IMHO.

 Right, if you use python (or anything) in your port, you have to declare
 the dependency in your port. Don't rely on it being there due to a
 dependency of another port because that other port could change in the
 future.

 > In the meantime, it probably doesn't matter exactly which python3
 version is used for building such ports (say, `port:exiv2`) so the
 proposed PG could include a bit of logic that makes them depend on the
 newest available interpreter (AFAIK that's more or less how clang
 dependencies are handled):

 That's contrary to the goal of ReproducibleBuilds. We do have a
 recommended python version. Currently it's 3.11. exiv2 uses that. You can
 read python-1.0.tcl to discover what the current recommended version is.
 It [https://lists.macports.org/pipermail/macports-
 dev/2021-December/044043.html will be updated to the latest stable version
 each January 1st]. Ports should be manually updated to that version as
 soon as possible after that. It should not be done automatically because
 there are any number of reasons why a port might be incompatible with a
 new version of python; for each port it needs to be tested individually.

 Most of what you've written here is not actionable as a ticket because it
 conflicts with established best practices. You could open discussions for
 these items on the mailing list if you'd like more input on whether these
 proposals could be made to work somehow.

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