Sopel should deprecate sopel_modules namespace packages

[dgw]

Existing packages in the sopel_modules namespace almost exclusively date back to the days of declaring a namespace using pkg_resources, and that module is deprecated. I'm just giving us a reminder for "someday".

The packaging documentation talks about legacy namespace packages and outlines cross-compatibility issues with the different methods of declaring them: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#legacy-namespace-packages

pkg_resources namespaces cannot coexist with implicit namespaces or pkgutil namespaces. In addition, even within each convention, the namespace logic can be broken by one installed package that doesn't follow the rules. (This would be a big part of why we started pushing entry-points as the future. A misconfigured entry point just doesn't work, but a misconfigured namespace package can break the whole namespace.)

This is why I suggest we deprecate the sopel_modules namespace starting in Sopel 8.1. I think there should be a deprecation warning when loading a sopel_modules plugin, just as there is when loading a plugin that still imports sopel.module.

sopel-irc/cookiecutter-sopel already discourages new namespace packages; the template now uses entry-point style. Packages' names will have to change no matter what, whether to switch to an entry point or to change namespaces—and thus I am not suggesting that we add support for a newer sopel_plugins namespace in which packages would be expected to follow the "implicit" or "pkgutils" style.

Having done a number of namespace-to-entry-point migrations myself, I'm confident in saying that it isn't very hard. Most of the time I spend on those migrations tends to be on making sure the package metadata is correctly moved to pyproject.toml, which I do at the same time, and not on changing the package structure.