#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 follow-up: 2 Changed 19 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | cal@… removed |
---|---|
Owner: | set to neverpanic |
Status: | new → assigned |
comment:2 Changed 19 months ago by ballapete (Peter "Pete" Dyballa)
Replying to ryandesign:
python.version
,python.versions
, andpython.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: | assigned → closed |
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.
python.version
,python.versions
, andpython.default_version
are all valid option names in the python portgroup.I cannot reproduce what you report. If I change
python.versions
andpython.default_version
to310
in the Portfile, it installs in the Versions/3.10 directory.