Cog packages starting with a strict prefix of redbot crash the drivers on load

[Kreusada]

What Red version are you using?

3.4.9 / 3.4.10.dev1

Cog name

CogManagerUI

Command name

load

What did you expect to happen?

For a private cog package to be loaded, named 'red'.

What actually happened?

The package failed to load, with the traceback provided below:

Exception during import of package
Traceback (most recent call last):
  File "/home/ubuntu/redenv/lib/python3.8/site-packages/redbot/core/core_commands.py", line 156, in _load
    spec = await bot._cog_mgr.find_cog(name)
  File "/home/ubuntu/redenv/lib/python3.8/site-packages/redbot/core/cog_manager.py", line 285, in find_cog
    return await self._find_ext_cog(name)
  File "/home/ubuntu/redenv/lib/python3.8/site-packages/redbot/core/cog_manager.py", line 221, in _find_ext_cog
    real_paths = list(map(str, [await self.install_path()] + await self.user_defined_paths()))
  File "/home/ubuntu/redenv/lib/python3.8/site-packages/redbot/core/cog_manager.py", line 72, in install_path
    return Path(await self.config.install_path()).resolve()
  File "/home/ubuntu/redenv/lib/python3.8/site-packages/redbot/core/config.py", line 176, in _get
    ret = await self.driver.get(self.identifier_data)
  File "/home/ubuntu/redenv/lib/python3.8/site-packages/redbot/core/drivers/json.py", line 138, in get
    partial = partial[i]
TypeError: 'NoneType' object is not subscriptable

This occured on the following bots:

Bot 1:
Version: 3.4.10.dev1
Py version: 3.8.5
Dpy version: 1.7.0
Storage type: JSON
System arch: aarch64
OS: Linux

Bot 2:
Version: 3.4.9
Py version: 3.8.5
Dpy version: 1.7.1
Storage type: JSON
System arch: AMD64
OS: Windows

I haven't looked into the side-effects of this, but it could be damaging to the backend. Perhaps a simple fix for this would be to check if the cog is named 'red' when loading, and return if it is - im happy to PR something for that. Obviously, a sensible workaround would be to just rename the package, but I still believe this should be handled.

Edit: This red cog does not use config. It doesn't matter whether they use config or not.

How can we reproduce this error?

1. Create a simple cog, with the package name as 'red', and the cog class as 'Red'. This can be installed from github, or loaded from a path, it makes no difference.
2. Load the cog, and get ready for your bot to error out on almost every command that evolves around config. For example, the basic [p]ping command will still function, because it does not use config. [p]info uses config to set custominfo, so this errors, same with help, or any customizable command.
3. Simply restart the bot for these errors to be pruned, I suggest then completely removing the cog from your bot.

[Drapersniper]

Red is a protected namespace, I wouldnt say this is an issue at all.

[Jackenmen]

This issue is not limited to "red", a cog named "r" would also cause this. Also, "red" is not a protected namespace, all people shouldn't (currently) do is name their cogs with anything that is an existing module. "red" (and "r" :)) is not an existing module so it should be working fine but it currently doesn't.

I made a fix for this for 3.4.x series (3.5 will change our import logic and hopefully resolve more weird issues with it). I would appreciate it if you could test it @Kreusada.

[Kreusada]

Yee, at the time I thought it was just Red that was the trigger, seems to be others, too.
Just tested with red, re, and r, and I can confirm that it does now work.

[Jackenmen]

Just to note, using re for module name is a bad idea currently as it's imported in main namespace and will affect anything that tries to import the re module from stdlib.

[Kreusada]

Just to note, using re for module name is a bad idea currently as it's imported in main namespace and will affect anything that tries to import the re module from stdlib.

Yes, I was aware of this and it wouldn't be smart to name a cog as re. I just wanted to test anyway from a message in AC.