"caddy add-package" could allow adding by version

[gedw99]

At the moment we cant control the version of the package added ?

The golang module system could allow us to add by tag or branch.

I expect many developers would want to use a tag ( as in git tag ) to help remediate supply channel attacks or other things of this nature.

caddy add-package -h

Downloads an updated Caddy binary with the specified packages (module/plugin)
added. Retains existing packages. Returns an error if the any of packages are
already included. EXPERIMENTAL: May be changed or removed.

Usage:
  caddy add-package <packages...> [flags]

Flags:
  -h, --help          help for add-package
  -k, --keep-backup   Keep the backed up binary, instead of deleting it

This would bring it inline with the list-modules --packages --versions command, which is version aware, so that its all consistent and all commands are version aware.

list-modules --packages --versions

Standard modules: 121

exec v0.0.0-20240603212820-a42a5b2ae10f github.com/abiosoft/caddy-exec
http.handlers.exec v0.0.0-20240603212820-a42a5b2ae10f github.com/abiosoft/caddy-exec

  Non-standard modules: 2

There is no point making caddy remove-package version aware since the binary can only have one version of a package.

final look and feel

For example, its is currently:

caddy add-package -h

Downloads an updated Caddy binary with the specified packages (module/plugin)
added. Retains existing packages. 

Returns an error if the any of packages are
already included. EXPERIMENTAL: May be changed or removed. 

with versioning it becomes :

caddy add-package -h

Downloads an updated Caddy binary with the specified packages (module/plugin)
added. Retains existing packages. 

Returns a success if the any of package versions are changed that are
already included. EXPERIMENTAL: May be changed or removed. 

[gedw99]

Note sure if it's a bug but caddy list-modules --packages --versions returns double listing of each module.

Maybe it should match how the standard modules look, which is tidy and also importantly able to be parsed by the space delimiter, for basic automation:

tls.stek.standard v2.8.4 github.com/caddyserver/caddy/v2

Here is the current output:

caddy list-modules --packages --versions

...

tls.stek.standard v2.8.4 github.com/caddyserver/caddy/v2

  Standard modules: 121

exec v0.0.0-20240603212820-a42a5b2ae10f github.com/abiosoft/caddy-exec
http.handlers.exec v0.0.0-20240603212820-a42a5b2ae10f github.com/abiosoft/caddy-exec

  Non-standard modules: 2

  Unknown modules: 0

[francislavoie]

What do you mean "double listing"? Nothing is doubled there. Do you mean exec? Those are in fact two separate modules.

[gedw99]

What do you mean "double listing"? Nothing is doubled there. Do you mean exec? Those are in fact two separate modules.

To me, it looks like it is the same module. but listed on 2 lines. Also the same version.

Relevant code is here ?

caddy/cmd/commandfuncs.go

Line 360 in dcbf38d

func cmdListModules(fl Flags) (int, error) {

[francislavoie]

They are separate. One is a Caddy app, the other is an http handler directive. Both come from the same package of course.

[gedw99]

What do you mean "double listing"? Nothing is doubled there. Do you mean exec? Those are in fact two separate modules.

To me, it looks like it is the same module. but listed on 2 lines. Also the same version.

Relevant code is here ?

caddy/cmd/commandfuncs.go

Line 360 in dcbf38d

func cmdListModules(fl Flags) (int, error) {

So it’s 2 lines of the same package ? Did you decide what it is ?

They are separate. One is a Caddy app, the other is an http handler directive. Both come from the same package of course.

Either way . It seems confusing visually to me. Probably to others too .

What would you suggest we do ?

[francislavoie]

Yes it's these two modules:

• https://github.com/abiosoft/caddy-exec/blob/a42a5b2ae10fe60b6215489d56763fc9a9270a59/app.go#L26
• https://github.com/abiosoft/caddy-exec/blob/a42a5b2ae10fe60b6215489d56763fc9a9270a59/middleware.go#L19

There's nothing confusing here. It's working exactly as intended. One is an App, one is HTTP handler, like I said. See the README for that package to understand the difference. The App is for "global config" and the handler is for per-site config.

[mholt]

Reopening since we could still allow specifying versions in the command

[gedw99]

Reopening since we could still allow specifying versions in the command

Hey @mholt

do you mean that your open to adding a version flag ?

[francislavoie]

It should probably match the xcaddy CLI syntax I think, i.e. @<ref> suffix to the package name.

[mholt]

Beat me to it, but yeah I think symmetry with the xcaddy CLI would be a good idea. package@ref syntax.