Python ports that don't have USE_PYTHON=noflavors should require all py-* dependencies to have @${FLAVOR}. Python ports that do have USE_PYTHON=noflavors should require all py-* dependencies to have @${PY_FLAVOR}. Non-python ports should require all py-* dependencies to have @${PY_FLAVOR}.
hmm, the request is not correct. In some cases, you want the default flavor as a dependency which is different from ${FLAVOR} and ${PY_FLAVOR}.
(default flavor = no @something at all)
(In reply to Antoine Brodin from comment #2) For python dependencies? Can python ports have any other flavors than pyNN?
I'm not sure what the ask is here, nor is it clear that something really needs to be done. Please be specific (examples of messages along with ports that do the wrong thing would be very much appreciated) as possible when asking for things like this in the future.
Since recent flavors commit, portlint has to check for flavor specifiers in python ports. Basic testcase: 1. cd devel/py-bandit 2. Remove @${FLAVOR} 3. "portlint -C" doesn't complain. It has to say "py-xx" dependency without @${FLAVOR} In case a python port has USE_PYTHON=noflavors, or in case the port isn't a python port, @${PY_FLAVOR} has to be specified in py-xx dependencies.
In short: Every py-xx dependency of any port has to have a flavor specifier. It should be @${FLAVOR} in python ports without USE_PYTHON=noflavors It should be @${PY_FLAVOR} otherwise.
Check add to my repo pending the next release.
Added to 2.18.0.
Why was this committed when I objected in comment #1 ?
Please revert the "Add a check to make sure Python dependencies include a FLAVOR [9]", I anticipate breaking changes due to this portlint error.
I didn't see your comment as the replies to my initial question came in after it. Why was this PR not just closed if it is wrong?
It was closed in comment #4 ...
But re-opened in comment #5, which is why I still had it in my todo list (and assumed it was still valid). Ugh.
Yuri, why did you re-open this when it was rejected? I don't want to play ping pong with this PR back and forth. So can you both agree what is needed here? Is it a full revert, or is there a way to take this forward?
Re-opening to track next steps.
(In reply to Joe Marcus Clarke from comment #15) Either full revert or turn it from an error to a possible warning (FATAL -> WARN and must -> may)
A commit references this bug: Author: marcus Date: Sat May 12 18:59:08 UTC 2018 New revision: 469754 URL: https://svnweb.freebsd.org/changeset/ports/469754 Log: Bump version to 2.18.1. Soften the py-* dependency error around flavors. Now the message is a warning and a suggestion. This is pending more discussion, but this seems like a good compromise for now. PR: 225654 Requested by: antoine Changes: head/ports-mgmt/portlint/Makefile head/ports-mgmt/portlint/src/portlint.pl
I have updated portlint to soften the error to a warning pending final consensus.
Please remove (or disable) the check entirely, as it is currently providing incorrect/ambiguous information in a few ways for entirely correct dependency lines, such as: py-tox: RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}py>=1.4.17:devel/py-py@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}pluggy>=0.3.0:devel/py-pluggy@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR} \ ${PYTHON_PKGNAMEPREFIX}virtualenv>=1.11.2:devel/py-virtualenv@${PY_FLAVOR} WARN: Makefile: you may want directory for dependency ${PYTHON_PKGNAMEPREFIX}py>=1.4.17 to be devel/py-py:@${FLAVOR} WARN: Makefile: you may want directory for dependency ${PYTHON_PKGNAMEPREFIX}pluggy>=0.3.0 to be devel/py-pluggy:@${FLAVOR} WARN: Makefile: you may want directory for dependency ${PYTHON_PKGNAMEPREFIX}six>0 to be devel/py-six:@${FLAVOR} WARN: Makefile: you may want directory for dependency ${PYTHON_PKGNAMEPREFIX}virtualenv>=1.11.2 to be devel/py-virtualenv:@${FLAVOR} * Suggests an incorrect syntax: "cat/port:@flavor" (the : is incorrect). It was perhaps a typo meant to be ":cat/port@flavor", but even if that was the case, the : is still unnecessary to display as the : is part of the known and separate dependency tuple syntax anyway. * Suggests FLAVOR incorrectly, should be PY_FLAVOR for python ports [1], at least in the current state. [1] PY_FLAVOR is available to depend on the correct version of Python modules. All dependencies on flavored Python ports should use PY_FLAVOR, and not FLAVOR directly.. (from Porters Handbook) As of right now, the check should remain disabled, unless and until the checks can be made completely accurate for all cases (flavors, noflavors), with no chance for false positives, which is just not possible at the moment given the state of flavor support: - overlap//conflict between generic port flavouring & python flavouring - the fact that ports currently must explicitly append flavours to origins versus have them implicitly added/modified via python.mk
The fix for this has been in the tree for a while, and I have not heard any more negative comments. I'm considering this closed. Please open a new PR if there is still undesired behavior.