Rework internal APIs for Command Line Tools

[Exirel]

After working on sopel.run_script and some internal features regarding configuration and modules loadings, it appears the internal APIs require a bit of love and care. There is a lot going on with that, so I'll try to list the things I think about:

• move CLI related code to sopel.cli.* sub-package,
• replace sopel.run_script by sopel.cli.run and adapt the setup.py's entry point accordingly,
• centralize how configuration files are found and loaded,
• centralize common CLI options (like -c config),

and I'm sure I'm forgetting some part.

For the record, I personaly worked on these PR before: #1429 #1434 #1445 #1465 - and others have worked toward the same goal (PR #1464 is a good example of that). Some PR have already been merged and some are closed until this issue is fixed.

Note: this is not an issue to discuss where the config files must be, or how to load modules. This is about making sure all the good ideas around how to structure internals APIs are shared.

[HumorBaby]

Feature request: allow for configuration of a specific module (as opposed to the current --configure-modules flag that asks y/n for each possible module).

Let me know if you make an "open call for patches" regarding this, and I will gladly contribute what I can :)

[Exirel]

Feature request: allow for configuration of a specific module

Hm. In #1465 I played with the idea of a sopel-config init, and something like sopel-module configure <module> or sopel-config module <mod-name> or something similar might work.

For that, I think we need to make sure all Configuration Wizards comply with the configuration loading, and that we can find the module as Sopel does when running it.

[HumorBaby]

Ah! I see now that's what ... init was meant to do.

[Exirel]

After a review of @dgw about add_config_arguments renamed add_common_arguments, I was thinking that there are 2 common options:

• -v/--version: show the program's version
• --verbose and --quiet: more/less output on stdout

[dgw]

@Exirel It might be more useful to have only long-form for --version and reserve the short args -v/-q as a pair for verbose/quiet.

We should (IMO) reassign -v and give --version the short form of -V instead. After adequate warning, of course.

(I lied in my original comment. I did have time to check the website listing of CLI args after all!)

[Exirel]

@dgw I fully agree @ --version/-V

[Exirel]

I was thinking about the run_script.py arguments: for actions like "restart" or "quit", it uses mutually exclusive options : --restart and --kill can not be used together.

In that case, I would change the command line from "options" to "arguments", like this:

$ sopel [action] [options]

Where action is run by default, and options is the list of common options + action-specific options.

This would be used like this:

$ sopel
$ sopel run --daemonize
$ sopel restart
$ sopel quit
$ sopel kill
$ sopel list-config
$ sopel wizard
$ sopel wizard --modules

For the record, these options are used in this order:

• --kill
• --quit
• --restart

Release Cycle

In 7.x I would:

• add the "action" argument, default to the "legacy" mode (no UX change)
• display a warning when options like --restart are used in legacy mode

In 8.x I would:

• change the default behavior from "legacy" to "run"
• remove the legacy mode completely

[dgw]

SGTM tbh. I have nothing to add, except that I like the "action" proposal.

[Exirel]

I like the "action" proposal.

I need #1472 to be merged first then. :D

[dgw]

I need #1472 to be merged first then. :D

Ask and ye shall receive! :D

[Exirel]

Since #1472 has been merged, I was able to work on:

• cli: move sopel.run_script to sopel.cli.run #1493 to move sopel.run_script in sopel.cli.run
• cli: add sopel-config {list,init,get} #1507 to provide a sopel-config CLI to work with configuration file
• cli: allow config loading from env (SOPEL_CONFIG) #1473 takes advantages of sopel.cli.utils #1472 to add a feature with very few lines of code

I'm quite happy with how #1472 turned out, and how it helps to add new features, and how cleaner it is to work for existing and new CLI tools.

Happy me!

Edit: I didn't use 1489 instead of 1493 here. That's fake news.

[dgw]

#1489 to move sopel.run_script in sopel.cli.run

Ah, that's #1493 isn't it?

Nothing to see here but FAKE NEWS…

[dgw]

With #1235 merged, what are the chances of making that easier to configure in future enhancements to the sopel-config CLI? It's a weird one, because it directly creates a config section per-channel and puts literal Python data structures (dict containing lists) in the values…

The selection interface you'll presumably implement to resolve #244 could be reused for choosing channels to configure, and picking modules/methods to disable.

Draft documentation for the feature is here.

[Exirel]

I think that would be more related to a sopel-plugins CLI, as in:

$ sopel-plugins disable-channel <modname>
$ sopel-plugins disable-channel <modname> <commandname>
$ sopel-plugins allow-channel <modname>
$ sopel-plugins allow-channel <modname> <commandname>

Or something alike. I don't know yet. But I like the {disable|allow}-channel stuff.

[Exirel]

Oh and by the way, that would require the new plugin interface, so it would be much easier to get a list of plugins, and from that list, to extract the available commands.

[dgw]

I think that would be more related to a sopel-plugins CLI

Fine with me, if there's other stuff to put there besides this one feature.

would require the new plugin interface

Is that (#1479) actually still WIP, or should I try to review it this week(end)?

[dgw]

This said:

I think that would be more related to a sopel-plugins CLI

Fine with me, if there's other stuff to put there besides this one feature.

I still think (en|dis)abling plugins on a per-channel basis is very much "config" related. I thought sopel-plugins would be more about managing plugins themselves, i.e. install/remove/search.

[Exirel]

Tough choice. I don't have the right argument yet, so I'll leave that for future me. I'm sure we'll figure out something meaningful and so obvious we'll feel bad not to find it sooner.

At the moment, #1479 is still a WIP, I want to fix something - that'll have to wait next week.

[Exirel]

Yay, #1479 got merged, and new things are coming in.

At the moment, I just pushed #1598 to allow such command: sopel start --config-dir /etc/sopel, which will look at /etc/sopel/default.cfg for its config file.

[dgw]

@Exirel Have you actually done everything you set out to do with this?

[Exirel]

Actually... yes, I think I did. It could always be better, but I don't think it's worth keeping that reminder in particular. I'd rather see new ideas and improvement in their own issues when they come by.