Summary: | [bsd.python.mk] [patch] Python version propagation breaks USE_PYTHON= usage for dependency builds | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Marcus von Appen <mva> |
Component: | Individual Port(s) | Assignee: | Marcus von Appen <mva> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | koobs, portmgr, python |
Priority: | Normal | Flags: | antoine:
exp-run?
|
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any | ||
Bug Depends on: | 192357 | ||
Bug Blocks: |
Description
Marcus von Appen
![]() ![]() graphics/openimageio defines USE_PYTHON=2.6+ graphics/blender defines USE_PYTHON=3.2 devel/boost-python-libs defines USE_PYTHON=2.5-3.1 If I install openimageio by itself it installs the python lib into the v2.7 python dir. If I install blender bringing in openimageio as a dependency it installs into v3.2 python dir, so that could be something to sort out. My guess is the openimageio pylib would need to use the same python version as boost-python-libs. Is there a reason boost-python-libs stops at 3.1? that was just the newest version at the time? could it be 2.6+ Blender uses python pretty heavily and I am certain it needs to stay against a specific version of python, I recall changes happening to upgrade support from python 3.1 to 3.2 Either way at this point blender is the only port using openimageio and the pylib being installed into python 2.7 or 3.2 libdir or disabling python bindings doesn't effect blender's use of libOpenImageIO. I'm not sure that blender would use the python bindings in the future. I am thinking this could be solved by breaking openimageio into two ports - one for a standard lib and another for python bindings. While this pr originated from graphics/blender (ports/167061) I will fix that as it's own issue as I think the issue of python dependency versions should be kept separate. As for python versions I'm not sure if that can be improved or just needs to be a check for port maintainers to verify that leaf ports use compatible python versions to their dependants. Do we need to consider ports being installed against multiple python versions? For reference I missed this as I built openimageio with python bindings using USE_PYTHON=2.6+ which led to the openimageio pylib and boost-python-libs being installed in the py27 libdir. When the new blender port was then built (using py32) it saw openimageio was installed but done no check to verify that it was installed into the same/compatible version of python. This also propagated within tinderbox as I built openimageio first and the existing packages were installed for dependants without testing python versions used. For others testing with tinderbox, adding a step of removing python using dependant packages before building a new port could be useful. Maybe a new tinderbox command/option to search for python using dependant packages for a port to be removed. Responsible Changed From-To: freebsd-ports-bugs->freebsd-python That's a Python PR Take for exp-run, as it was requested on https://phabric.freebsd.org/D387 Exp-run results: http://package18.nyi.freebsd.org/build.html?mastername=91amd64-default-PR167368&build=2014-07-25_13h55m26s There are 3 new failures, but for 2 of them I believe it will fix a previously broken behaviour (egginfo with a strange path) + {"origin"=>"devel/py-gobject3", "pkgname"=>"py27-gobject3-3.8.1_1", "phase"=>"package", "errortype"=>"PLIST"} + {"origin"=>"devel/py-ice", "pkgname"=>"py27-Ice-3.5.1", "phase"=>"build", "errortype"=>"missing_header"} + {"origin"=>"devel/py3-gobject3", "pkgname"=>"py33-gobject3-3.8.1_1", "phase"=>"package", "errortype"=>"PLIST"} Failures logs: http://package18.nyi.freebsd.org/data/91amd64-default-PR167368/2014-07-25_13h55m26s/logs/errors/py27-gobject3-3.8.1_1.log http://package18.nyi.freebsd.org/data/91amd64-default-PR167368/2014-07-25_13h55m26s/logs/errors/py27-Ice-3.5.1.log http://package18.nyi.freebsd.org/data/91amd64-default-PR167368/2014-07-25_13h55m26s/logs/errors/py33-gobject3-3.8.1_1.log devel/py-ice right now does the right thing, since PYTHON_VERSION is set in the environment. A simple MAKE_ENV+= PYTHON_VERSION=${PYTHON_VERSION} fixes the issue (as described in ${WRKSRC}/py/config/Make.rules). py-gobject3 uses a wrong substitute that is easily fixed with changing the egg-info entry in pkg-plist (use %%PYTHON_VER%% instead of %%PYTHON_VERSION%%) and adding a PLIST_SUB+= PYTHON_VER=${PYTHON_VER}. Committed in rev. 364450 |