One of my deployment pipelines on Azure DevOps fails when executing the build module images action of Azure IoT Edge task. I am trying to deploy a custom module developed using the Azure IoT SDK for C# (.NET 6).
Error message:
##[error]/usr/lib/python3/dist-packages/requests/__init__.py:89: RequestsDependencyWarning: urllib3 (1.26.12) or chardet (3.0.4) doesn't match a supported version!
I tried to include this solution as CmdLine task before the build task. It worked a few runs and then failed again.
The pipeline already had a "Temporary fix" installing iotedgedev separately as a workaround for this bug
The deployment logs don’t tell much about where to focus. I wonder what could be the cause of this issue? and if there is a quick fix or something to avoid while developing the application (i.e. warning messages while building or something like that)
3
Answers
Short answer -> force pyOpenSSL to version 22.0.0 (Edited 09.01.20223)
The cause seems to be a reported bug related to a dependency issue connected to a new pyOpenSSL release: github.com/Azure/iotedgedev/issues/589
pyOpenSSL>=20.0.1 on iotedgedev requirements resolves pyOpenSSL-22.1.0 creating some conflict with urlib or chardet
In this case, a temporary fix needed a "quick" temporary fix :D
I’ve had the same problem. After checking previous success Pipelines it seems that then new iotedgedev version 3.3.5 has a problem in DevOps Build Task (I haven’t investigate more)
To fix that, at least temporally, I have added a Command Line Script before Build Modules Images Task that installs version 3.3.4.
It has worked for me, but as I said is a temporally patch.
As this appears to happen again and again and again and again (in different flavours), I felt it made sense to explain why this happens. It’s right there in the error message actually, in my case:
So, apparently the requests package needs its dependencies at a certain version level to work correctly. But
pip
doesn’t show which versions:Let’s look at init.py then, this is where the error occured:
….and on it goes, and we can now fiddle around with the expected version strings until the warning goes away or update the
requests
package to a version that accepts its required packages at the correct versions.TL;DR: One has to upgrade or downgrade the affected packages (
request
or its dependencies) to get it right, or fiddle around withrequests/__init__.py
until the warning goes away 🙂