python subpackage build error ... not a supported wheel on this platform

[Brian Inglis]

On 2022-03-13 07:04, Jon Turney wrote:
> On 12/03/2022 17:54, Brian Inglis wrote:
>> Building locally I get the message below on 64 & 32 bit package builds:
>> ERROR: python_nghttp2-1.47.0-cp38-cp38-cygwin_3_3_4_x86_64.whl is not 
>> a supported wheel on this platform.
>> but not in the confines of a scallywag build: what do I need to remove 
>> or change to build locally?

> What have you tried?

Installing every python*-{devel,pip,setuptools,wheel} package in sight!
See bottom for inherited and installed package lists.

> The packages installed by scallywag are recorded in the build log, so 
> have you looked at that to see what's installed there but not locally?
> 
> At a guess, it might be that you need python38-wheel or python38-pip 
> installed, which scallywag arranges to be installed when it sees 
> 'inherit python-wheel' [1]
> 
> [1] 
> https://github.com/cygwin/scallywag/blob/85647ca844226100006d22537d728332130b4462/analyze.py#L171 

Tried config with --enable-python-bindings as well as usual opposite to 
build with cygport using cython.
Just tried uninstalling python*-{tox,virtualenv} and dependencies
python-{pip,setuptools,wheel}-wheel with no change!
Will next try inherit python3-wheel instead of python-wheel and use 
python3_wheel_{compile,install}.

That gets me further and results in:

>>> python38-nghttp2-1.47.0-1.tar.xz
tar: usr/lib/python3.8/site-packages/*nghttp2*: Cannot stat: No such 
file or directory
tar: Exiting with failure status due to previous errors
*** ERROR: Binary package creation failed: python38-nghttp2

Reading through cygport cygclass python/3-wheel docs, it implies that 
using generic python-nghttp2 in PKG_NAMES should expand to specified 
(default) versions (now python38-nghttp2, python39-nghttp2) rather than 
having to explicitly specify the latter?

Will try and see if that works as expected and perhaps helps: no - only 
latest version built, not both 3.8 and 3.9.

Now local and scallywag consistently fail not building python 3.8 package!

Reverting to python-wheel from python3-wheel.

Just found /usr/local/bin/pip{,3,3.8} with explicit #!/usr/bin/python3.8 
same date as curl 7.75 release over a year ago, so there must have been 
some issue to workaround, which never had any impact until this package 
and release! Sorry for the noise!

That all now seems to work properly locally and on scallywag.


#====================================================
#Inherited and Installed Scallywag and Local Packages
#====================================================
$ egrep inherits scallywag/*86*/6_*.log | cut -d' ' -f3- | sort -ur
scallywag: cygport inherits: python-wheel
scallywag: build dependencies (deduced from inherits): 
python2-pip,python2-wheel,python3-devel,python36-pip,python36-wheel,python37-pip,python37-wheel,python38-pip,python38-wheel,python39-pip,python39-wheel
# above does not include python2/7-devel, python3[67]-devel
$ egrep 'install\spython[^-]*-(devel|pip|setuptools|wheel)'	\
	scallywag/*86*/[46]_*.log | awk '{print $5}' | sort -u
python27-pip
python27-setuptools
python27-wheel
python36-pip
python36-setuptools
python36-wheel
python37-pip
python37-setuptools
python37-wheel
python38-devel
python38-pip
python38-setuptools
python38-wheel
python39-devel
python39-pip
python39-setuptools
python39-wheel
python3-devel
$ apt-cyg l python*-{devel,pip,setuptools,wheel} | cut -d' ' -f1 | \
	sort -u
python27-devel
python27-pip
python27-setuptools
python27-wheel
python2-devel
python2-setuptools
python36-devel
python36-pip
python36-setuptools
python36-wheel
python37-devel
python37-pip
python37-setuptools
python37-wheel
python38-devel
python38-pip
python38-setuptools
python38-wheel
python39-devel
python39-pip
python39-setuptools
python39-wheel
python3-devel
python3-pip
python3-setuptools
python3-wheel
python-pip-wheel
python-setuptools
python-setuptools-wheel
python-wheel-wheel

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]