looking at the source, python is only used for "make dist" and maybe for pypi distribution. the Arch package does not use python: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/knot. I tested the package removing USES = python and it appears to compile and operate correctly.
python-sphinx is used when building docs, so can be conditional.
I'd like to merge this report with PR 242665 to keep the number of open PR's limited.
(In reply to Leo Vandewoestijne from comment #1)
It's preferable and less confusing to separate bugfixes (this bug) from updates (bug 242665) so that the former (bugfixes) can be merged to the quarterly branch, whereas version updates, unless they are bugfix only releases, generally are not.
This PR can be closed;
it's addressed in PR 242665 - see patch #210967 or later.
^Triage: Correct resolution, resolved by bug 242665
not fixed... DOCS_USE=python means that pkg install knot2 also requires python, because knot2 pkg is built with DOCS...
python is only build time dependency, not runtime. but moreover, USE is not correct in the first place... python is only required by sphinx, which is not even provided as a dependency, so sphinx-build is not there anyways? but moreover, sphinx is not even required for docs... sphinx is only required for *regenerating* man pages after changing source files...
so idfk what is going on here, but looks to me like everything is wrong.
This is now addressed in the patch of PR 247263
It now should only use Python as build dep. and only in case DOCS was desired.
(In reply to Leo Vandewoestijne from comment #6)
It's not clear to me how this resolves any of the actual issues with the building of the documentation that I raised in comment 5, only the single issue of "pkg install knot2" unnecessarily installing python. Sphinx is not specified as a dependency, so the requirement of python appears to be two-fold useless: the documentation does not need to be regenerated (since it is not being patched), and moreover the actual required dependency (sphinx) is not being included in a clean build environment.
@Reporter/Maintainter: What is the currently proposed change?
Should be fixed with https://svnweb.freebsd.org/changeset/ports/539974
Hmm, re-reading comment 5, it looks like we should re-analyse this solution from https://svnweb.freebsd.org/changeset/ports/539974
So, DOCS needs sphinx only if the docs are regenerated after some change.
If they are installed (DOCS=on) in the general case, sphinx is not necessary.
sphinx will need python, so do we need USES=python ? Or will sphinx
bring this automatically ?
And: DOCS=on is default, so we're back to square one anyway ?
So, we should probably have a seperate port knot2-docs, which has
all the depends, and knot2 has no DOCS knob.
Is that a solution that we can all agree on ? Or does that look too messy ?
See previous comment.
(In reply to Kurt Jaeger from comment #12)
This assessment of the current situation appears correct to me.
In my opinion, since knot2 port does not currently patch the docs, it seems easiest to me to simply remove DOCS knob entirely. Then, if the user wants to add a patch for docs, it is their responsibility to patch the pre-generated man files.
Alternatively, DOCS could build PDF, HTML, and texinfo documentation. In that case, sphinx, pdflatex, and makeinfo are required.
In any case, python is still not required. Python is an implementation detail of Sphinx and the consumer need not manually install Python. That is the whole point of dependency trees: the consumer specifies which programs it wants, and the package installs the required libraries internally.
Created attachment 216110 [details]
knot2 w/o python
The DOC knob still is required for PORTDOCS.
But indeed python is not of any practical use.
Attached my patch to remove it.
A commit references this bug:
Date: Sun Sep 13 01:55:27 UTC 2020
New revision: 548443
dns/knot2: Update to 2.9.6
Remove Python from DOCS option, it is not necessary at this moment. 
PR: 243374 
Submitted by: Leo Vandewoestijne <firstname.lastname@example.org> (maintainer)
Reported by: email@example.com