textproc/py-scour: force *default* Python as a dependency

[avilla]

Summary

An incoming port, www/nuvolaplayer-deezer, will depend on
textproc/py-scour while using 'python:3'. That, as explained in
poudriere#259 [1], would break PACKAGE_BUILDING (as in
ports-mgmt/py-pytoport).
An easy solution to this is to force a Python version (python:2) in
py-scour USES, considering that the port was just added, and no other
port depends on it (thus, there is no current interest in being able
to build it with a specific Python version).

py-scour itself depends on devel/py-six, and the issue might repeat
itself in environments with DEFAULT_PYTHON != 2.7 (custom package
trees?).
The real solution is to force the build of py-scour with the default
version of Python, thus making sure that - when PACKAGE_BUILDING - it
finds py-six package.

The hack may be removed (and 'concurrent' added) when VARIANTS support
lands into ports.

[1] https://github.com/freebsd/poudriere/issues/259

[dbn]

A specific observation: you don't need to bump PORTREVISION as USES=python defaults to using PYTHON_DEFAULT.

Generally: I don't understand what problem you are trying to fix. Please would you provide instructions on how to reproduce the error. As I understand the problem: if you are building using Ports (not poudreire) then the framework will build a py3 version of the port (in addition to the current default of py2 version). To fix building with poudriere we create a slave port (py3-scour) for consumption by USES=python:3 ports.

This patch will simply cause the py3 version to fail, instead of building. I suggest you change the port to allow for USE_PYTHON=concurrent.

Some notes: this patch will break when D8069 (eventually) breaks and it breaks existing behaviour around the explicit PYTHON_VERSION usage (i.e. if PYTHON_DEFAULT=2 and PYTHON_VERSION=3 then the port currently produces a package whereas the patch will fail).

[avilla]

You're right, my patch would break as much as it would try to fix.

Anyway, I'm abandoning the revision, but I'll try to explain myself better.
Consider port A using python:3 depending on port B using only python. When PACKAGE_BUILDING is set (Poudriere, Synth), this happens:

1. the list of dependencies is calculated on port origins; PYTHON_VERSION is derived from PYTHON_DEFAULT_VERSION, thus py27-B is scheduled for build
2. py35-A gets finally built; it depends on B, but now PYTHON_VERSION is inherited from A's python:3, thus py35-B is requested, but no package was built for it
3. the build fails

So far, this solution has been implemented (taken from ports-mgmt/py-pytoport, but it's used in most - if not all - ports using python:3 depending on ports using only python, as in my example):

.if defined(PACKAGE_BUILDING) && ${PYTHON_VER} != ${PYTHON_DEFAULT}
IGNORE= you have python ${PYTHON_DEFAULT} set as the default, and this needs ${PYTHON_VER}
.endif

In my case this is a bit more complicated, as I have www/nuvolaplayer-deezer with python:3 depending on textproc/py-scour, which depends on devel/py-six; both use only python. After some thought, to be completely sure that packages can always be built I should add ports textproc/py3-scour and devel/py3-six, which seems overkill. I will add IGNORE to www/nuvolaplayer-deezer (which currently would block other packages from being built) and just make it an option (disabled by default) in packages depending on it.