py37-tensorflow @2.2.0: ERROR: tensorflow-2.2.0-cp37-cp37-macosx_10_14_x86_64.whl is not a supported wheel on this platform.

[ryandesign (Ryan Carsten Schmidt)]

After 6 hours of compiling, ​py37-tensorflow @2.2.0 failed to destroot on macOS 10.14:

WARNING: Requirement '/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_python_py-tensorflow/py37-tensorflow/work/tensorflow-2.2.0-cp37-cp37-macosx_10_14_x86_64.whl' looks like a filename, but the file does not exist
ERROR: tensorflow-2.2.0-cp37-cp37-macosx_10_14_x86_64.whl is not a supported wheel on this platform.

This error message is similar to #60318 but I'm not familiar enough with this software to judge whether it's the same issue or not.

[cjones051073 (Chris Jones)]

I noticed when testing this on my 10.15 machine here that the whl file made at the end changed its name a little, see the last diff in

[42ff42ce12bca1cf8294d5062a4f416b037e2357/macports-ports]

that seems to have worked on 10.15 but not in other places.... And yes its really annoying this happens at the very end of a mammoth build... :(

I think the best thing here is to not try and guess the file name, but as there will only be one under ${workpath} use a glob approach to just find it...

[ryandesign (Ryan Carsten Schmidt)]

Replying to cjones051073:

I think the best thing here is to not try and guess the file name, but as there will only be one under ${workpath} use a glob approach to just find it...

That sounds good.

[ryandesign (Ryan Carsten Schmidt)]

According to [493ffa29839dfd1dee572ae55499176536c821f9/macports-ports] some ports may need to be rebuilt for the m change to fully propagate. Any way we can identify which ports those are, and do that?

Presumably the reason why there is a difference between 10.14 and 10.15 is that binaries of tensorflow's dependencies were built for those systems at different times. Maybe 10.15 already got the m change and 10.14 didn't, or vice versa.

[ryandesign (Ryan Carsten Schmidt)]

Maybe let's solve that first. See comment:ticket:60104:13.

[ryandesign (Ryan Carsten Schmidt)]

Here's the same failure on py38-tensorflow1: ​https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/59302/steps/install-port/logs/stdio

It looks like py-tensorflow1 is still unconditionally using the m suffix, and py-tensorflow is unconditionally not using the m suffix. But the m suffix is dependent on the python version. It is only used for python 3.0 through 3.7 inclusive. It is not used for 3.8 or later nor for python 2. So indeed using glob to find out what filename got built would be simplest.

[cjones051073 (Chris Jones)]

Yeah, I a) Didn't realise the change was python version dependent and b) thought it was something tensorflow was doing so the 1.x version did not need it.

Should be fixed by

[c63702340a39c0f64853ee859a5f3ad7bfcd5709/macports-ports]

I did a quick test here, turning off the build step and instead creating an empty test whl file instead, and the wildcard found it, so it should hopefully work..

[ryandesign (Ryan Carsten Schmidt)]

Thanks. I guess we'll know tomorrow! :)

[mascguy (Christopher Nielsen)]

Support for Python 3.7/3.8 has been dropped for py-tensorflow, so this ticket is no longer relevant. Closing.