[MacPorts] #67347: asciidoc @10.2.0_2: Portfile declares one variable but uses a different one

[MacPorts]

#67347: asciidoc @10.2.0_2: Portfile declares one variable but uses a different one
------------------------+------------------------
  Reporter:  ballapete  |      Owner:  neverpanic
      Type:  defect     |     Status:  closed
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.8.1
Resolution:  invalid    |   Keywords:  tiger ppc
      Port:  asciidoc   |
------------------------+------------------------
Changes (by neverpanic):

 * status:  assigned => closed
 * resolution:   => invalid


Comment:

 This behavior is correct. The supported interface to set the supported
 python versions in the python 1.0 PortGroup is `python.versions`, the
 supported interface to set the default is `python.default_version`. Now,
 since `python.versions` is set to a single version, setting
 `python.default_version` is possibly redundant, at least as long as nobody
 changes the list of Python versions.

 This is because setting `python.versions` actually calls
 `python_set_versions` in the PortGroup due to the `option_proc
 python.versions python_set_versions` statement. If you look at
 `python_set_versions`, you'll see that it's a rather lengthy proc that
 does a myriad of things.

 Not setting `python.version` causes it's default of `[python_get_version]`
 to be executed when the variable is read, i.e. the value of the variable
 is computed at runtime when it is first read.

 I know it looks a bit strange, but it's the common way to use the Python
 PortGroup, and I don't see a reason to deviate from it. If your locally
 changed Portfile installs in
 `${frameworks_dir}/Python.framework/Versions/3.11`, then whatever change
 you made is not correct.

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