asciidoc @10.2.0_2: Portfile declares one variable but uses a different one

[ballapete (Peter "Pete" Dyballa)]

     45 python.versions     310
     46 python.default_version \
     47                     310
     48 depends_build-append \
     49                     port:py${python.version}-setuptools
     50 depends_lib         port:python${python.version} \
     51                     port:libxml2 \
     52                     port:libxslt \
     53                     port:docbook-xml-4.5 \
     54                     port:docbook-xsl-nons
     55 depends_run         port:fop
     56 depends_test        port:py${python.version}-pytest \
     57                     port:py${python.version}-pytest-mock

Since I think one version of Python 3 is sufficient I am setting some Portfiles to use Python 3.10 until all ports will use Python 3.11. Due to the mismatch of variable names asciidoc gets installed in

x ./opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/asciidoc-10.2.0.dist-info/

etc.

[ryandesign (Ryan Carsten Schmidt)]

python.version, python.versions, and python.default_version are all valid option names in the python portgroup.

I cannot reproduce what you report. If I change python.versions and python.default_version to 310 in the Portfile, it installs in the Versions/3.10 directory.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

python.version, python.versions, and python.default_version are all valid option names in the python portgroup.

That's obvious. Otherwise this Portfile would not have been put into production. The question is why two variables are set to a value that corresponds to a Python version and then a third one is used that is set by the "system"? In other words: python.versions should be python.version without final "s".

[neverpanic (Clemens Lang)]

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.

[jmroot (Joshua Root)]

There's actually no need to set python.versions at all in asciidoc because it's not a module that you want to have a subport per python version.