Ensure every plugins can build

[darkweak]

Closes #98

[polarathene]

If possible to use the newer v3 release of Badger that would be good. I was under the impression the build failure was due to a dependency on an RC v2 version of Badger (which is apparently from smallstep/nosql).

I believe the issue was actually resolved when you updated dependencies as just 2 days ago, smallstep/nosql updated that RC v2 dependency to the latest v2 release. Perhaps downgrading the version of v3 for you was just coincidence in timing and mislead you as the solution? (EDIT: May still take a little longer as Caddy has yet to update to that newer version (PR), and of course make a release)

[polarathene]

Downgrading Badger v3 prevents Caddy from building? That isn't due to the prior commits build failure was it? That was about an RC version of Badger v2 AFAIK.

At least when I used xcaddy I used --with to override for latest v2 release and it build successfully avoiding the same build failure error I linked which was experienced in my bug report.

There was some nice improvements in the newer releases of Badger v3, if there was another issue that you experienced with building Caddy can you reference it and any related Github issue to track?

[polarathene]

If upgrading to newer Badger v3, there is a native Go version of zstd to replace the datadog CGo dependency.

Caddy will still depend on the datadog one due to dependency on smallstep/nosql having a upgrade blocker to Badger v3, but a Caddy maintainer has set up a PR for Badger v2 to backport this zstd dependency change. (EDIT: Not sure about the datadog dependency for Caddy, since Caddy apparently builds with CGo disabled)

[francislavoie]

BTW, go.sum is not dependencies, it's just all the collected hashes of sources in the dependency graph. It doesn't actually mean that version will be used in the build.

The go.sum file may contain hashes for multiple versions of a module. The go command may need to load go.mod files from multiple versions of a dependency in order to perform minimal version selection.

https://golang.org/ref/mod#go-sum-files

[polarathene]

BTW, go.sum is not dependencies, it's just all the collected hashes of sources in the dependency graph.

Thanks for the clarification! I'm a Go noob 😬

It doesn't actually mean that version will be used in the build.

Is it building a dependency when I get errors like this from xcaddy?:

/go/pkg/mod/github.com/dgraph-io/badger/v2@v2.0.1-rc1.0.20201003150343-5d1bab4fc658/table/table.go:849:18: not enough arguments in call to z.Calloc   

Updating that RC version to newer using xcaddy --with resolved it. AFAIK that version of badger is/was a dependency of smallstep/nosql that was recently updated and Caddy will update as well.

Presumably it was a minimal version for v2 because of the RC suffix, so semver rules to use a newer version were invalid? (that or there was no other Badger v2 versions referenced so it settled on that one? 🤷‍♂️ )

The go.sum is like yarn.lock/cargo.lock from what you've described. Will it be stale and still reference the wrong version causing a build error after Caddy updates? (assuming that the go.sum for this module will need to be updated, even if go.mod is updated or I use xcaddy --with for the newer Caddy release)

Hopefully this PR is enough to prevent the build issues in future 😅

[francislavoie]

Is it building a dependency when I get errors like this from xcaddy?:

smallstep/nosql just happened to have last updated its badger dependency to that v2.0.1-rc1 release, so that's what was used. I don't know why that particular error was happening. Too deep down the chain, and I don't super care to dig to find out. I just want the CGO dependencies gone ASAP 😬 but the recent version bump to the latest v2 of badger should be a decent stopgap even if my PR for backporting the removal of DataDog/zstd isn't merged anytime soon.

The go.sum is like yarn.lock/cargo.lock from what you've described.

That's essentially my understanding, yeah. Go stores the actual sources in your GOPATH somewhere, and those versions and hashes are references to specific versions, so Go can verify that what's in the go.sum matches what was downloaded out of band.

Will it be stale and still reference the wrong version causing a build error after Caddy updates?

As the link I sent above explains, any go get or go mod tidy command updates the go.sum automatically, so it's typically kept up to date pretty well.

[darkweak]

I'll merge without tag a new version and (me or someone else) will open another PR to bump deps when the one on the badger repository will be merge on it.