Caddy's import path has changed

[mholt]

Caddy's import path (and Go module name) has changed from

github.com/mholt/caddy

to

github.com/caddyserver/caddy

Unfortunately, Go modules are not yet mature enough to handle a change like this (see https://golang.org/issue/26904 - "haven't implemented that part yet" but high on priority list for Go 1.14) which caught me off-guard. Using Go module's replace feature didn't act the way I expected, either. Caddy now fails to build with plugins until they update their import paths.

I've hacked a fix into the build server, so downloading Caddy with your plugin from our website should continue working without any changes on your part, for now. However, please take a moment and update your import paths, and do a new deploy on the website, because the workaround involves ignoring module checksums and performing a delicate recursive search-and-replace.

I'm terribly sorry about this. I did a number of tests and dry-runs to ensure the change would be smooth, but apparently some unknown combination of GOPATH, Go modules' lack of maturity, and other hidden variables in the system or environment must have covered up something I missed.

This bash script should make it easy (run it from your project's top-level directory):

find . -name '*.go' | while read -r f; do
    sed -i.bak 's/\/mholt\/caddy/\/caddyserver\/caddy/g' $f && rm $f.bak
done

We use this script in the build server as part of the temporary workaround.

Let me know if you have any questions! Sorry again for the inconvenience.

[ghost]

@mholt That should do it. :)

[mholt]

@whalehub Uhhh wow! That's a lot! I didn't even know about some of these.

Thank you for taking the initiative!

[ghost]

@mholt Will all of these plugins have to be rewritten from scratch to work with Caddy v2?

[mholt]

@whalehub That's an interesting question.

• Some v1 plugins won't be needed at all in v2 because of v2's expanded capabilities. Or, the functionality of some v1 plugins are being rewritten as officially-developed modules for v2, even if they don't come standard (for example, the v2 cache module will probably be spliced out from the standard modules before a stable release, but we'll still maintain and develop it officially).

• The core functionality of a v1 plugin probably need not be written, especially if it's just an HTTP handler; i.e. you can more or less keep the ServeHTTP method with a few tweaks.

• Parsing of Caddyfile tokens isn't very different in v2, so you can probably keep that code, too, albeit with different function signature and a few tweaks.

• Some of the more advanced/involved/complex v1 plugins should probably take this opportunity to rewrite for v2; for example, I'd like to see the git plugin written as a self-contained, pure-Go solution, rather than shelling out to external git commands. Any module that keeps long-running or global state may need to be redesigned.

I'll eventually write some more guides than what we have now for developing on v2, but I'm going to wait at least until the release candidates for that.