Page MenuHomeFreeBSD

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

Authored by avilla on Jan 7 2017, 4:06 AM.


Group Reviewers

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
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
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.


Diff Detail

rP FreeBSD ports repository
No Linters Available
No Unit Test Coverage
Build Status
Buildable 6618
Build 6836: arc lint + arc unit

Event Timeline

avilla retitled this revision from to textproc/py-scour: force *default* Python as a dependency.
avilla updated this object.
avilla edited the test plan for this revision. (Show Details)
avilla added a reviewer: Python.

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).

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):

IGNORE= you have python ${PYTHON_DEFAULT} set as the default, and this needs ${PYTHON_VER}

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.