DisnakeDev
Migrate off of legacy namespace packages
See https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#pkgutil-style-namespace-package
We currently use legacy namespace packages, though we should migrate to pep440 compatiable namespace packages.
This however, has the potential to break some extensions, so proper research should be investigated before continuing.
As someone who's developed extensions into the disnake.ext namespace multiple times, I can only agree with this. The argument of "it's not compatible with PEP440" aside, it's painfully inconsistent with a lot of tooling (at the time) and sphinx also has a lot of trouble figuring out (ext)links when there's a disnake package and an entirely separate disnake.ext.foobar package. It ended up being so much of a hassle that I ended up moving both extensions out of the namespace.
Besides the novelty of having nicely unified namespaces for extensions, I don't really see a benefit of this either; and I really don't think it makes a lot of sense how - at least in its current state - disnake is barely useable without relying on what is effectively considered an extension (i.e. disnake.ext.commands). I think for this issue to really be resolved, we'd need to consider which parts of ext-commands to integrate into the base lib, and turn the rest into a real extension that does not inherently ship with disnake anymore. Perhaps we could still provide an optional install of disnake[commands] or similar.
This kind of ties back into what I expressed in disnake: I think it's fine if we take one major version update to just restructure the whole lib and break a bunch of things where needed, as a change like this requires a fair amount of restructuring anyway; which also ties in with #1360 to some extent.
We don't need to migrate our repositories or anything. This is simply about using https://peps.python.org/pep-0420/ to create our namespace packages rather than pkgutil.
This still doesn't solve any of the issues that non-first-party extensions face, as they would still need to provide their own disnake.__init__ file that exactly matches disnake's (Revelant Poetry discord message chain that initially taught me why I was experiencing issues with this when developing extensions), even with PEP420 this is still required if the top-level package is not a namespace package itself due to import order not being guaranteed in python.
It's a change we can make, but I don't think it holds any benefit if we don't make changes elsewhere too.