[PyQt] sip-build --debug and wheels on a Raspberry Pi

[Kyle Altendorf]

On 2020-04-08 11:35, Phil Thompson wrote:
> On 08/04/2020 16:17, Kyle Altendorf wrote:
>> On 2020-04-08 10:26, Phil Thompson wrote:
>>> On 08/04/2020 13:03, Kyle Altendorf wrote:
>>>> On 2020-04-08 07:29, Phil Thompson wrote:
>>>>> On 08/04/2020 04:10, Kyle Altendorf wrote:
>>>>>> 2) Building a wheel with pip on an ARM Raspberry Pi results in a 
>>>>>> file
>>>>>> with manylinux2014_x86_64 in the name.  Perhaps something based on
>>>>>> distutils.util.get_platform() (plus pep425 described modification 
>>>>>> of
>>>>>> the value) and replacing linux with manylinux<whatever>?  Or you'd
>>>>>> think some official library would expose this calculation for you 
>>>>>> to
>>>>>> use.
>>>>>> 
>>>>>>     PyQt5-5.14.2-cp35.cp36.cp37.cp38-abi3-manylinux2014_x86_64.whl
>>>>>> 
>>>>>> Backstory: I'm trying to help piwheels get a build going for 
>>>>>> PyQt5.
>>>>> 
>>>>> <whatever> is chosen according to the glibc requirements of Qt. It 
>>>>> is
>>>>> specified using 'minimum-glibc-version' in ...
>>>>> 
>>>>> https://www.riverbankcomputing.com/static/Docs/sip/pyproject_toml.html#tool-sip-project-section
>>>> 
>>>> Sorry, I added to my description and it became less clear.  The
>>>> concern is the x86_64 part, I have no knowledge of errors in the
>>>> manylinux part.  Raspberry Pi are armv7l.  PEP425 describes building
>>>> the platform tag, albeit without the manylinux part.
>>>> 
>>>> https://www.python.org/dev/peps/pep-0425/#platform-tag
>>>> 
>>>> So maybe distutils.util.get_platform().replace('-', 
>>>> '.').replace('.',
>>>> '_').replace(sys.platform, the_selected_manylinux_tag).  Or maybe 
>>>> the
>>>> wheel package has something, etc.  I haven't looked at what this 
>>>> does
>>>> in macOS so I certainly may still be way off.
>>>> 
>>>>     >>> distutils.util.get_platform().replace('-', '.').replace('.',
>>>> '_').replace(sys.platform, 'manylinux2014')
>>>>     'manylinux2014_x86_64'
>>>> 
>>>>     >>> distutils.util.get_platform().replace('-', '.').replace('.',
>>>> '_').replace(sys.platform, 'manylinux2014')
>>>>     'manylinux2014_armv7l'
>>> 
>>> manylinux is only defined for Intel platforms.
>>> 
>>> I assume a normal setuptools is being used to build these...
>>> 
>>> https://www.piwheels.org/project/PyQt5-sip/
>>> 
>>> ...so it would seem to make sense to follow that convention.
>>> 
>>> Can you tell me *exactly* what get_platform() returns in a Pi?
>> 
>> It looks like manylinux2014 added references to non-intel 
>> architectures.
>> 
>>     https://www.python.org/dev/peps/pep-0599/#the-manylinux2014-policy
> 
> Thanks. I assume we can treat armv6l in the same way.

It doesn't list it so I would have assumed not.  But I haven't dug into 
the manylinux stuff too far.

>> On the Raspberry Pi I am running on (from Mythic Beasts, where
>> piwheels does their builds):
>> 
>>     root at raspberrypi:~# /usr/bin/python3 -c 'import distutils.util;
>> print(repr(distutils.util.get_platform()))'
>>     'linux-armv7l'
>> 
>> To include the Pi version:
>> 
>>     root at raspberrypi:~# cat /proc/device-tree/model
>>     Raspberry Pi 3 Model B Plus Rev 1.3root
>> 
>> At this point I am just getting a procedure setup to build _some_
>> PyQt5 wheel.  From there I'll check back with piwheels to see what
>> their existing mechanisms are and how to fit into them.  Also what
>> adjustments should be made to make a proper wheel.  I'm sure I'll
>> learn several things as I work through this.
> 
> Can you check with Ben now that 'manylinux2014_armv7l' will be Ok?
> 
> Note that this is different to what setuptools on the Pi seems to do.
> The issue is whether pip on the Pi is new enough to handle
> manylinux2014. If not I'll provide an option for the default to be
> overridden.

     root at raspberrypi:~# pip3 --version
     pip 18.1 from /usr/lib/python3/dist-packages/pip (python 3.7)
     root at raspberrypi:~# dpkg -S $(which pip3)
     python3-pip: /usr/bin/pip3

manylinux2014 support was added in pip 19.3 so no, it isn't supported 
for system installation.  I personally would use a virtualenv or venv 
but it would presumably be nice to support using system pip.  Given it 
doesn't work with system pip I don't plan on asking Ben, but if you 
still want their input I still could.  Or we could move the discussion 
to the linked issue?  Hopefully I'll get my first reference procedure 
posted later today.

Cheers,
-kyle