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

MacPorts noreply at macports.org
Thu Sep 7 13:04:01 UTC 2023


#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:
 Keywords:           |       Port:
---------------------+--------------------
 There are projects that require Python in some form, for building or
 because they build Python extensions (often as part of a more complex
 build) without using one of the regular Python build systems.

 These usually need knowledge about the custom Python install layout in
 MacPorts. The logical approach would be to include the Python PG to obtain
 the necessary definitions, but that would redefine the build system in a
 way that is probably impossible to revert.

 The other day I threw together a personal port for `d-feet`, which obliged
 me to copy a number of definitions from the Python PG.

 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.

 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.

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

 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):

 {{{
 python.build_with_version_suggested 3.11
 # ...
 set python.build_with_version ${python.build_with_version_suggested}
 for {set v [lindex [split ${python_version} .] 1]} {${v} >= 0} {incr v -1}
 {
     if {[file exists ${prefix}/bin/python3.${v}]} {
         ui_debug "Python 3.${v} is available; using it as a depends_build"
         set python.build_with_version "3.${v}"
         break
     }
 }

 depends_build-append port:python${python.build_with_version}
 }}}

 Or, using a do/while construct (e.g. https://wiki.tcl-
 lang.org/page/do..while) :
 {{{
 set v [lindex [split ${python.build_with_version} .] 1]
 do {
     if {[file exists ${prefix}/bin/python3.${v}]} {
         ui_debug "Python 3.${v} is available; using it as a depends_build"
         set python.build_with_version "3.${v}"
         break
     }
 } while {[incr v -1]}
 }}}

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


More information about the macports-tickets mailing list