Bug 255579 - devel/py-pip: Fails to build with DOCS enabled: SyntaxError: future feature annotations is not defined
Summary: devel/py-pip: Fails to build with DOCS enabled: SyntaxError: future feature ...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Po-Chuan Hsieh
Keywords: needs-patch
Depends on:
Reported: 2021-05-03 20:53 UTC by John Hein
Modified: 2021-05-05 02:38 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (python)


Note You need to log in before you can comment on or make changes to this bug.
Description John Hein 2021-05-03 20:53:20 UTC
When DOCS option is on, the build calls 'setup.py build_sphinx'.  This error occurs when using python3.6:

  File "/tmp/pip-20.3.4/docs/docs_feedback_sphinxext.py", line 3
    from __future__ import annotations
SyntaxError: future feature annotations is not defined

20.3.4 has a new docs_feedback_sphinxext.py file which has:

from __future__ import annotations

This fails with python3.6.

Workaround: WITHOUT=DOCS for python3.6

The easy change is probably to change USES=python:3.6+ to 3.7+ (this could be dependent on whether DOCS is on but that is probably more trouble than it's worth).
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-05-04 00:51:18 UTC
Thank you for the report John.

pip declares support for 3.5+ [1], this issue has been reported upstream.

Re the easy change in comment 0, Python ports must not set Python support <version-spec> arbitrarily. It is a declarative expression of version support, not an imperative one to use specific versions.

[1] '>=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*',
Comment 2 John Hein 2021-05-04 15:54:31 UTC
(In reply to Kubilay Kocak from comment #1)
Yes, I did see that python_requires='>=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*' in setup.py and considered that.

My [brief] thinking was:

We already deviate from the upstream 'requires' spec due to overriding freebsd project concerns, namely: we don't support python2.7 or python3.5 anymore.  So that's why the port has USES=python:3.6+ - if we strictly adhered to a regurgitation of the upstream requirement spec, it should have USES=python:2.7,3.5+.  But, of course, this case is different since it is not _freebsd_ that chose not to support the older versions, but upstream (although possibly unintentionally) when they added the new requirement without updating 'requires'.

The freebsd port chooses to optionally build the documentation (if DOCS is on). Upstream may consider 'build_sphinx' a second class citizen when considering its 'requires'.  If so, then it seems it would be okay to set USES=python:3.7+.  If not, then I agree it is just an outright upstream bug.  I suspect you're right, and they DON'T consider build_sphinx a second class citizen, so the full-on 'bug' moniker would be correct.

That said, until they fix upstream, our ports tree is [slightly] broken (especially since DOCS is on by default).  So that's the main reason I advocated setting USES=python:3.7+ for now - that can be a reasonable temporary workaround (at least when we build with DOCS).

The breakage is pretty minor, however, since the default python version is now > 3.6.  Because of that, very few people will hit this bug.  If you don't think it's worth our time to commit anything to address the breakage, that's okay with me.  I can just close this with a "won't fix" resolution.  For now, I'll just let this sit and wait a while to hear from upstream.

For reference, here is the upstream issue report (yes, that was from me):
No bites yet.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2021-05-05 02:38:21 UTC
" we don't support python2.7 or python3.5 anymore.  So that's why the port has USES=python:3.6+ "

Yep, I understand how this may have seemed to be the case. However, there are no actual overriding project concerns. 

Excluding python versions by imperatively changing individual version specs, versus another method, either a temporary measure in individual ports or at the framework level, which derived the highest or best Python version to use given a certain <version-spec> was not appropriate and unfortunately set a poor precedent that we need to remedy.

The correct resolution here will be one of, upstream fixes the bug, restoring support for the versions they declare support for (ie; its a bug), or version support is updated to reflect the current reality.

It's definitely worth our time to fix it.