What modules should be out of sopel's core and how to do that?

[Exirel]

After reading issues like #1435, #700, #1037, or code like the .py command, I wonder what should be a built-in module.

Here are some reasons I know (both the ones I thought about and the ones I've heard about):

• if they need configuration (like API key), they should be externals,
• if they rely on an API that is shutdown, they should be externals, or replaced promptly,
• it's hard to release a bugfix for a module, because it requires a sopel full release,
• and btw there is Package-ize core plugins #1291 that say explicitly that we should remove modules from core but there is an issue that blocks it so it's complicated...

Here are some advantages I can think of when doing that:

• external module can tell which version of Sopel it is compatible with,
• external module can be fixed and released without having to upgrade Sopel and all other modules,
• external module can be uninstalled without having to uninstall or modify Sopel's code,
• external module can be listed as Git Repository somewhere,
• they can have their own documentation,
• also Package-ize core plugins #1291 is important,

Here are some issues or needs we need to address, now or later, in a near or distant future:

• "how to create a module" documentation,
• even more documentation,
• better test tools for developers of external modules,
• some documentation, too,
• a way to distribute and install single-file module without using pip install (even though pip install is the best option, not all users are able to use it properly),
• you know what? documentation,

And many more.

Oh, and while I'm here, listing things, here is how I would do the transition from "all is built-in" to "nothing is built-in":

• step 1: extract selected modules into their git repository, and their proper python package, that can be installed with a pip install sopel-module.<modname>
• step 2: in release 7.0.0, put all these ex-core modules into the setup.py's requirements,
• step 3: add a big warning message on the documentation
• step 4: remove them from the requirements of release 8.0.0

As a conclusion, I want to mention again that (we need documentation shhhh) issue #1291 already exists, and this issue is more or less a way, for me, to discuss further the needs for that to happen, rather than the if it should happen. It'll happen, but how to make sure it's a success is the question I'm interested in at the moment.

PS: also did I talk about documentation? I'm sure I should talk about it more but I don't know how exactly.

[dgw]

I appreciate the thoughts, but I do disagree on the split between tracking whether this is done and how it should be done. This discussion belongs in #1291 with the other packagization talk, in my opinion. 😸

If you're willing to keep the whole discussion in one place, just copy your comment from here to that issue (edited to avoid self-references of course 😆) and close this. I'll then mark it as a duplicate.