A proposal for a Caddy plugin manager / dev tool

Plugins
1

Along with @abiosoft and @captncraig, I’ve been mulling over ideas for a tool to aid Caddy plugin developers and Caddy users who just want to manage plugins for their installation like packages. This tool would effectively replace caddydev and caddyext from pre-0.9 versions.

I am approaching this as a kind of wrapper to the go command. Right now, to build caddy “properly” (with version information), you need to run build.bash (Unix-only) which runs go build. We would replace build.bash with this tool and it would be written in Go, so cross-platform.

Here are my thoughts so far. Note that I haven’t decided on a name for the tool yet, so I just use “cadgo” in its place here because it’s kind of a Caddy-specific wrapper over the go command.

(Be sure to scroll to see full proposal.)

$ cadgo build
	Basically same as build.bash (which is just `go build` with version info).

$ cadgo build github.com/mholt/caddy
	For when you're not in the repo's folder.

$ cadgo build github.com/mholt/caddy with github.com/abiosoft/caddy-git
	Same as above, but with git plugged in.
	Can have multiple plugins specified.

$ cadgo build from github.com/mholt/caddy
	When you're in your plugin's folder and want to try it out real quick.
	Caveat: We have to assume import path from cwd.
	If the 'from' syntax is weird, we could do this instead:
		$ cadgo build github.com/mholt/caddy with .
		 or
		$ cadgo build github.com/mholt/caddy with this

All the above would work with `cadgo run` or `cadgo install` as well.
These just wrap `go run` and `go install`, respectively.

For a "package manager" style use, for modifying your local `caddy`
instance (like caddyext did):

$ cadgo add http.git
	- Contacts the plugin registry for an import path
	- Runs `go get` (-u?)
	- Adds the import to github.com/mholt/caddy/caddy/caddymain/run.go
	- Runs `cadgo install`

$ cadgo remove http.git
	- Contacts the plugin registry for an import path
	- Removes the import
	- Runs `cadgo install`

(Should `add` and `remove` subcommands take import paths instead
of plugin names?)

Note that for this tool to work (at least the add/remove commands), it will require constructing a new central plugin registry. I have some plans for this already, and the new build server will also use this new plugin registry.

This tool does require go and VCS to be installed (git is most common of course). I figure only developers will be using this tool anyway. People who just want custom caddy builds can use the build server.

What do you think?

2 Likes
2

Is this from/with syntax common? I’ve never seen it before and it looks really weird to me.
Wouldn’t it be better to use normal syntax like --plugins, --path?

Other than that this proposal looks good to me.

Edit: I like http.git for add/remove. It’s much easier to remember than import path’s. I’d be constantly referencing the path of stuff.

1 Like
3

What about:

$ cadgo build
–source //can be . or PATH or Github Link
–addplugin
→ Contacts the plugin registry for an import path
→ Runs go get (-u?)
→ Adds the import to github.com/mholt/caddy/caddy/caddymain/run.go
→ Can have multiple plugins specified.
–delplugin
→ Contacts the plugin registry for an import path
→ Runs go get (-u?)
->Removes the import from github.com/mholt/caddy/caddy/caddymain/run.go
->Can have multiple plugins specified.
–plugintest “IMPORT PATH”
->removes all other plugin imports.
→ Adds the import to github.com/mholt/caddy/caddy/caddymain/run.go
->Can only have ONE plugin specified.

$ cadgo install
–dest //If not specified caddy file is installed to /usr/local/bin

$ cadgo run

4

I really dislike modifying the github.com/mholt/caddy tree to add plugins. It makes it a bit odd when I need to update and go get -u -v github.com/mholt/caddy fails when there are unstaged changes.

1 Like
5

I know that’s inconvenient, but it kind of has to be that way, doesn’t it? If a developer uses RegisterDevDirective(), they will be importing the “real” caddy repo, not a copied repo that the tool keeps maintained elsewhere.

I actually think it’s good to be extra aware of the state of plugins when doing VCS changes. And you should be able to do a pull most of the time anyway, unless there’s a conflict or something, right?

6

Not particularly common, but I’m going for something memorable, quick to type, etc. The CLI is very simple in this case anyway.

Good to know, will probably keep it that way.

7

Wouldn’t it be more memorable if it felt like using any other Linux command? Being intuitive is more important here.

To me this would be like doing git commit say 'update config'

8

What the status of this proposal? 'Cause I need (frequently) to build from source and add some (non-public) plugins?

For CoreDNS we’ve opted for a (very) simple model where you just edit middleware.cfg (https://github.com/coredns/coredns/blob/master/middleware.cfg) and then ‘go gen’ the files needed. No external tools needed.

9

I haven’t been working on it as I’ve been working to finish the new website and build server stuff.

A text file list isn’t a bad idea. I’ll look into that too!

10

awesome! Let me know what you think. It would be really cool if we could share they way to add plugin between CoreDNS and Caddy.