(Summarising conversation from Discord)

Agree that we should do this, but need to figure out a backwards compatibility story.

• People who install this manually can choose to rename to urequests.py to match how their existing code uses it.
• Ports/boards that freeze this will need to be updated to require("requests") but then this will break existing code when firmware is updated.
• Boards with current firmware that do upip.install("urequests") will continue to work (as the download files are already published) but will be stuck at the current version. (Although we're unlikely to do future updates to the current package repository anyway, as it's being replaced)

So the second point is the main concern. I think for better or worse, we have to continue to freeze something that can be imported with "import urequests" for the forseeable future.

Here are some ideas:

• We do this change, but then also add back a urequests package with from requests import * and make its manifest do require("requests"). In other words, installing/requiring "urequests" implicitly gets you "requests" but you can keep using import urequests.
• We add urequests.py to the requests package with from requests import *. So you need to now install/require "requests" but can continue to use import urequests as both files will be copied to the device.
• We special-case this in the manifest/freezing/packaging/upip mechanism (perhaps add an alias() command to manifest.py?). The result being that this repo only has "requests.py", but on the device, no matter which way you install/freeze it, you automatically get a urequests.(m)py.

Similar story for uasyncio.

I just don't think there should be a u module in eco-sys that's my main concern. There might be one more option so officially only 4 boards freeze urequests, the whole esp8266 port is really old likely not used anymore, the NANO and PICO_W are brand new, I'd say only the esp32 will likely be using ureqeuests heavily, so maybe a breaking change for 8266 and the rp2 boards, as for esp32 how about creating some new dir in micropython-lib called obsolete or something like that and adding urequests there ? New esp32 boards should freeze requests.

esp32/boards/manifest.py:require("urequests")
esp8266/boards/GENERIC/manifest.py:require("urequests")
rp2/boards/PICO_W/manifest.py:require("urequests")
rp2/boards/ARDUINO_NANO_RP2040_CONNECT/manifest.py:require("urequests")

With the suggested change for removing u for builtins with alias to previous u names, is it worth considering having the alias handled in import rather than case by case?
Aka for any code importing any module starting with u, if it's not found, fallback to looking for same thing without u?

I'm wary of ever adding such broad "magic" but in this case maybe it's worth it to simplify the clean up of so many different kinds of module names?

the whole esp8266 port is really old likely not used anymore

We still see lots of people talking about the esp8266 port in the forum and get occasional bug reports too.

New esp32 boards should freeze requests.

Unlike rp2, the esp32 (and esp8266) manifest includes urequests at the port level, and therefore all boards. We can't have some boards have "requests" and some boards have "urequests".

We need to make "import urequests" continue to work on esp32/esp8266 for the foreseeable future.

how about creating some new dir in micropython-lib called obsolete or something like that and adding urequests there ?

This might be a good option. It will mean that tools/manifestfile.py (main repo) and tools/build.py (this repo) need to update to know about the new directory. The other option is to move it to the micropython directory. Either way it does mean that the manifests need to continue to require("urequests") though, which isn't ideal.

That said, I think my preference is for the second option that I proposed above...

• We can update the manifests to require("requests") (clearer and more obvious)
• Users can continue to import urequests.
• You must mip install requests (but that's probably a good thing to make it clear, and because mip is new there's no compatibility there to worry about)
• There will be no directory named urequests in python-ecosys.

The only downside is that there's an extra urequests.py in the python-ecosys/requests directory, but it's clear what it's doing.

I think the same approach works for asyncio too.

Okay I've updated this PR to include urequests.py, and once it's merged and microython-lib submodule is updated, just ping and I can send another PR to micropython to fix the manifests.py files that require("urequests.py"). That said, I think that for new ports/boards it should be okay to make a breaking change to use require("requests.py"), which is better than maintaining their current manifest.py forever.

I thought about this some more, and I think I'd rather go with the first option.

• There's just too much stuff out there that refers to the module as urequests, so we should keep a top level urequests package that can be mip-installed or frozen. But I agree this shouldn't be in python-ecosys. micropython/urequests is a good enough alternative (unless we later implement an obsolete directory or something)
• It's unfortunate to have to include urequests.py if someone just installs requests. So having it separate means we can control exactly whether to also add urequests. Right now this is done through bundle-networking.
• Doing from requests import * copies the modules dict, using up RAM. It's more efficient to use the getattr trick we've been using elsewhere.

Implemented this in #702

Renamed in 8513bfb