cmd: Unwrap adapter modules to get underlying modules

[WeidiDeng]

Fix 5621.

In addition, this also fixed several add(remove)-package related commands as they can't be used to add or remove adapter related modules.

Before,

After,

[mholt]

Oh, thanks for this!

I was kind of thinking that we should rethink this command...

Technically, by "modules" I mean "config modules" i.e. an extension of the configuration.

I wonder if this command should actually be "list-plugins" to list all the plugins.

Or maybe the semantics shouldn't matter and we should just print everything.

The problem is that config adapters don't keep the same interface as a Caddy module... so we'd have to figure that out.

Can we talk about a fix where we don't wrap the adapters in the first place? I think I'd like that better. 😁

[WeidiDeng]

You mean adapters are not part of modules, and will not show as so. However, they will show in the new list-plugin command?

They are of course affected by add / remove package commands.

[WeidiDeng]

What should be the definition of a plugin? Maybe just config-adapters are more expressive?

[mholt]

Well, I'm not sure if a new list-plugins command is the right answer -- maybe it is. I need to think about it more, or maybe have a discussion about other good solutions.

[mholt]

Revisiting this...

this also fixed several add(remove)-package related commands as they can't be used to add or remove adapter related modules.

Are you sure this doesn't work? It should still "plug in" the adapters and download the resulting build, even if they don't appear in the list.

I still hesitate to print adapters as if they were config modules with names like caddy.adapters.* because they aren't config modules. They're plugins, at least... but the list-modules command is for config modules.

I think perhaps there is a solution, but probably not this PR. I hope that's OK. Thank you for working on this nonetheless.

What I think we should do instead, to describe the config adapters supported by a Caddy build, is to properly set the Accept header in the admin API, since the Content-Type header is what determines which config adapters to use.

I'm going to close this, but we can open a new PR to set the Accept header. Thanks for understanding, @WeidiDeng. You are great.