CoreS3 & HTTP Request block: urequests import error

[ajb2k3]

I think the issue lies with the fact it’s importing urequests as request Try adding

‘’’ import urequests ‘’’

[streammyevent]

This results in:

Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
ImportError: no module named 'urequests'
>>> 

[ajb2k3]

Well that's odd

[_andreas_]

Hi,

I'm very new and just startet with M5Dial and UIFlow 2.0.1 yesterday.

Adding http as Software and a HTTP request block results in this import line:
import urequests as requests

which leads to the error stated above:
ImportError: no module named 'urequests'

For me a fix ist to switch the code view to Custom Edit and rewrite this line as
import requests

or
import requests as requests

Now the code compiles and http requests are working.

But for every change in the UI one have to reset the Custom Edit and enable it with this change again before doing another Run.

Looking at this it seems that urequests have been renamed to requests 7 month ago. As far as I've read, UIFlow is based on MicroPython.

They created a wrapper for urequests which would even help in our case:

The MicroPython version of requests was previously called urequests and a lot of existing code depends on being able to still import the module by that name.
This package provides a wrapper to allow this. Prefer to install and use the requests package instead.

Any guess howto add a custom module in UIFlow 2.0 or tell the http block to import requests instead of urequests or update the used version of MIcropython?

Kind regards

[ajb2k3]

Add a execute block and type in the import request function

[ajb2k3]

@streammyevent said in CoreS3 & HTTP Request block: urequests import error:

This results in:

Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
ImportError: no module named 'urequests'
>>> 

Sorry that should have been requests not urequests

[_andreas_]

@ajb2k3 said in CoreS3 & HTTP Request block: urequests import error:

Add a execute block and type in the import request function

I'm not sure if I get you right.
I can add the custom import using a execute block.
But this will add a new import line to the bottom of imports and the problematic import import urequests as requests will still exist in the code generated by UIFlow 2.1. Therefore the error persists.

Here is a screenshot of what I'm talking about:

It's weird anyway, as the Web console states, that MicroPython 1.22 is running, which should contain the Wrapper package urequests anyway.

[MadeFL]

This was my original question really.

If I add any HTTP block into UiFlow2.x then it will include import urequests in the code.

This will fail, even if I add an import requests myself.

So my solution was to use a code block instead of a http block to perform the task I wanted, but a little on the clumsy side and not really what UiFlow was meant to be used.

I wonder if I imported reuqests as urequests and then urequests as request it would fool it?

Tim

[ajb2k3]

@_andreas_ said in CoreS3 & HTTP Request block: urequests import error:

@ajb2k3 said in CoreS3 & HTTP Request block: urequests import error:

Add a execute block and type in the import request function

I'm not sure if I get you right.
I can add the custom import using a execute block.
But this will add a new import line to the bottom of imports and the problematic import import urequests as requests will still exist in the code generated by UIFlow 2.1. Therefore the error persists.

Here is a screenshot of what I'm talking about:

It's weird anyway, as the Web console states, that MicroPython 1.22 is running, which should contain the Wrapper package urequests anyway.

Sort of but you are actually importing my the library Twice but with different names. Which in theory will sometimes fix the issue if it can’t find a library with one of the names.

It’s a bridge fix if one of the libraries is spelt wrong in the import as we have here

[mikeluyten]

urequests is not a typo, the u stands for μ, the Greek symbol for micro. Meaning: "micro"-requests, a smaller version of the requests library, slimmed down for micropython.
I have read that urequests has also now been replaced by urllib.request as a further optimised version for low memory ESP devices.

I believe the included "requests" library may be too large for the memory of the S3, and urequests IS the intended library that should be included in the firmware (which it is not)

Using requests instead of urequests in my code I get the following error:
File "requests/init.py", line 180, in get
File "requests/init.py", line 93, in request
OSError: [Errno 12] ENOMEM

[_andreas_]

@mikeluyten said in CoreS3 & HTTP Request block: urequests import error:

I believe the included "requests" library may be too large for the memory of the S3, and urequests IS the intended library that should be included in the firmware (which it is not)

this is imho not the point of this topic. The problem is, that using the http block in UIFlow 2.0.1 leads to an invalid import. The block must be adopted to either import requests instead of urequests or someone has to check, why the urequests wrapper package from Micropython cannot be loaded (which should load requests due to the renaming in Micropython 7 month ago).

Until than, http block is not usable without editing the code afterwards (which leads to the fact, that one cannot longer use the UI for programming).

For now I've solved it by replacing all http blocks with Execute my python blocks containing these two lines:

http_req = requests.get('http://my.local/url', headers={})
http_req.close()

Since I do not need the response this is even shorter than using the http block.

[_andreas_]

Hi,

FYI: I've got a response from m5stack support regarding this issue:

Below issue is caused by the mpy version changing. We may fix it by next version, which should be next Friday. Thx!

[mikeluyten]

@_andreas_ said in CoreS3 & HTTP Request block: urequests import error:

Hi,

FYI: I've got a response from m5stack support regarding this issue:

Below issue is caused by the mpy version changing. We may fix it by next version, which should be next Friday. Thx!

Can confirm, this is now fixed!