The title seems clear but what I see is that building textproc/asciidoc ver 8.6.10 seems to have this in the Makefile : USES= autoreconf gmake gnome python:2.7 shebangfix However in /etc/make.conf we clearly have : hydra# cat /etc/make.conf DEFAULT_VERSIONS+=python=3.7 DEFAULT_VERSIONS+=ssl=openssl111 DEFAULT_VERSIONS+=perl5=5.28 hydra# This seems to be respected on x86_64 thus : vesta# uname -a FreeBSD vesta 12.0-RELEASE-p4 FreeBSD 12.0-RELEASE-p4 GENERIC amd64 vesta# Wherein pkg query shows that python 3.7 seems to be fine as a dep : vesta# pkg query %t\ %n\ %v\ %o | sort -n . . . 1560322345 gsed 4.7 textproc/gsed 1560322531 python37 3.7.3_1 lang/python37 1560322685 p5-Error 0.17027 lang/p5-Error 1560322764 bash 5.0.7 shells/bash 1560322847 getopt 1.1.6 misc/getopt 1560322962 libxml2 2.9.8 textproc/libxml2 1560323293 libgpg-error 1.36 security/libgpg-error 1560323321 libgcrypt 1.8.4_1 security/libgcrypt 1560323333 libxslt 1.1.32 textproc/libxslt 1560323441 xmlcatmgr 2.2_2 textproc/xmlcatmgr 1560323447 iso8879 1986_3 textproc/iso8879 1560323448 docbook-sgml 4.5_1 textproc/docbook-sgml 1560323454 xmlcharent 0.3_2 textproc/xmlcharent 1560323455 docbook-xml 5.0_3 textproc/docbook-xml 1560323457 sdocbook-xml 1.1_2,2 textproc/sdocbook-xml 1560323458 docbook 1.5 textproc/docbook 1560323462 docbook-xsl 1.79.1_1,1 textproc/docbook-xsl 1560323468 libpaper 1.1.24.4 print/libpaper 1560323502 libltdl 2.4.6 devel/libltdl 1560323515 libatomic_ops 7.6.10 devel/libatomic_ops 1560323529 boehm-gc 8.0.4 devel/boehm-gc 1560323557 w3m 0.5.3.20190422 www/w3m 1560330207 xmlto 0.0.28 textproc/xmlto 1560330226 asciidoc 8.6.10_1 textproc/asciidoc 1560330305 pcre2 10.32_1 devel/pcre2 1560330313 cvsps 2.1_2 devel/cvsps 1560330385 git 2.21.0 devel/git 1560330395 wget 1.20.3 ftp/wget . . . Note that at no time was python 2.7 dragged in. However on ppc64 we seem to be force fed python 2.7. Feels wrong to me. Is there some hard reason why python 3.7.3 does not do all that we need for asciidoc?? ps: yes I know this is seen on PPC64 and a lot of work is going on there but the architecture should be of no concern. see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863 -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
I see nothing wrong here. The title describes a correct action. You have to read Mk/Uses/python.mk for more details. USES=python:2.7 means this port needs a python 2.7 interpreter (lang/python27). DEFAULT_VERSIONS+=python=3.7 means your default python is lang/python37.
Maybe I said this wrong but what I was trying to get to was that I already have python 3.7.3 built and installed from ports and I do NOT want another version of python around. I can not see a need for python 2.x within asciidoc or am I wrong here? If so then why does asciidoc build and install fine on x86_64 with python 3.7.3 however over on ppc64 that seems to not work out? I certainly do not know. I was under the false notion that /etc/make.conf was here to say just use the existing python 3.7.3 but maybe that doesn't work.
> I was trying to get to was that I already have python 3.7.3 built and > installed from ports and I do NOT want another version of python around. If you try to build textproc/asciidoc with Python 3.x, you'd immediately notice this error: > ===> Building for asciidoc-8.6.10_1 > gmake[2]: Entering directory '.../work/asciidoc-8.6.10' > Fixing CONF_DIR in asciidoc.py > Fixing CONF_DIR in a2x.py > /usr/local/bin/python3.6 a2x.py -f manpage doc/a2x.1.txt > File "a2x.py", line 79 > print '%s: %s' % (PROG,msg) > ^ > SyntaxError: invalid syntax The code is still using 2.x syntax (print statement) and thus cannot be built with new Python as is (without patching). Feel free to craft a patch. :-)
From the (8.6.10) README [1]: NOTE: The current version of AsciiDoc requires *Python 2.6 or 2.7* to run. There is an open issue for a Python 3 port: python 3 port of asciidoc https://github.com/asciidoc/asciidoc/issues/83 Currently the port exists as a 'fork' with its own site, not as a PR against upstream asciidoc code. Efforts to have upstream code support Python 3 should be directed upstream. At present, asciidoc requiring 2.7 is a reflection of actual and current Python support upstream, and is intended behaviour / not a bug [1] https://github.com/asciidoc/asciidoc/blob/8.6.10/INSTALL.txt
(In reply to Alexey Dokuchaev from comment #3) I think crafting a small patch is the best way forwards. At least for now. Thank you.
(In reply to Dennis Clarke from comment #5) If adding Python 3.x support is going be a proposed change, these should be submitted upstream as a first course of action, as there are already open works in progress for Python 3 support This issue is closed as existing behaviour is not a bug (read: intended behaviour). Any proposals to backport upstream changes to improve or add Python support should take place in a separate/new issue, referencing this one in "See Also" if desirable.