search

Azure / azure-uamqp-python

AMQP 1.0 client library for Python
MIT License
57 stars 47 forks source link

Support for ARM based releases (such as for Raspberry PI) #15

Open digimaun opened 6 years ago

digimaun commented 6 years ago

We have user requests for pre-built ARM based releases (like for armv7l) to support straight-forward uamqp usage on devices like Raspberry PI's.

annatisch commented 6 years ago

Piwheels are already making builds for uamqp for Raspbian for Python 3.4 and 3.5: https://www.piwheels.org/ https://www.piwheels.org/simple/uamqp/

However these packages require OpenSSL to be installed. In my tests OpenSSL seems to already be present by default. Though my tests so far have only been on docker containers rather than a real Raspberry Pi.

If your setup doesn't already have OpenSSL, you should be able to install:

$ apt-get update
$ apt-get install libssl-dev

@digimaun - it would be great if you could try this package out on actual hardware and provide some feedback here :)

In the meantime I will continue to attempt to build an ARM ready manylinux wheel.

rafwaf commented 5 years ago

Is ARM (Raspberry Pi specifically) "natively" supported in SDK-Python(event hub in particular, version 5.0.2b) or does it still require an independent installation of UAMQP and OpenSSL? Is this still truly an Open issue?

It is unclear to me, as OpenSSL seems to be included in Raspbian-Buster(or is it only in Debian-Buster), which is the latest version of Raspbian, so as I understand it, this should all be resolved ( another evidence is that UAMQP seems to install just fine on the pi). However, data is still not being received on my client (on the Pi).

Thank you very much for any clarification of the current situation.

annatisch commented 5 years ago

Hi @rafwaf - If you can get the module to install on the Pi then you should be good to go. You will know if OpenSSL is an issue if you try to import/run the library and you get some interesting errors about missing symbols.

If you're not seeing any errors, and it otherwise appears to be running, it looks like it will likely be another reason that your client isn't receiving data.

The reason for this thread it to have specific ARM wheels built. But if you're able to build directly from the sdist, that would be unnecessary :)

rafwaf commented 5 years ago

Thanks @annatisch . I Guess it is something else then. Good luck with development :)

annatisch commented 5 years ago

Thanks @rafwaf - I'm currently working on pure-python port of this library which will hopefully support wider platform compatibility and easier debugging for this kind of thing.

rafwaf commented 5 years ago

@annatisch That is great. I know one of our interns was having some issues with the current python wrapper version on the Pi, and saw the comment in the docs about it being in development. I'm happy to hear it again from you :) p.s. he worked around it on th pi by sending the data from python, over a socket, to NodeJS, since the NodeJS SDK did seem to work on the Pi and then sent the telemetry up to Azure. Long story short, I'm looking forward to the pure Python version 👍

sdebruyn commented 4 years ago

It would already help a lot if wheels were provided for ARM64, would it be much more work than adding that arch to the CI/CD pipeline?

sdebruyn commented 4 years ago

Looks like this would mean moving from manylinux2010 to manylinux2014

rringham commented 3 years ago

Is there an update on this? It's still not possible to directly pip install azure-servicebus on a Raspberry Pi without apparently jumping through a bunch of hoops, and that's not sustainable for RPi devices.

The strong preference here would be to not have to fight uamqp on a RPi.