Opened 19 months ago

Closed 19 months ago

Last modified 19 months ago

#67347 closed defect (invalid)

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

Reported by: ballapete (Peter "Pete" Dyballa) Owned by: neverpanic (Clemens Lang)
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: tiger ppc Cc:
Port: asciidoc

Description

     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.

Change History (4)

comment:1 Changed 19 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: cal@… removed
Owner: set to neverpanic
Status: newassigned

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.

comment:2 in reply to:  1 Changed 19 months ago by 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".

comment:3 Changed 19 months ago by neverpanic (Clemens Lang)

Resolution: invalid
Status: assignedclosed

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.

comment:4 Changed 19 months ago by 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.

Note: See TracTickets for help on using tickets.