Provide an extra zip/tar.gz release archive with Go vendoring included for reproducibility

[anthonyfok]

Due to the dynamic nature of the Go library packages that Hugo depends on, our released source code in zip or tar.gz form could soon become unusable by the end user. For example, it is probably very difficult for an end user to build hugo v0.15 from source from https://github.com/spf13/hugo/archive/v0.15.tar.gz without going back in time for some dependencies. Even more difficult to re-create the exact same released v0.15 binaries from source.

I recommend providing an extra zip/tar.gz source archive with the vendoring information added, e.g., generated by the following commands:

export GOPATH=/tmp/hugo-gopath
govendor get -v github.com/spf13/hugo
cd $GOPATH/src/github.com/spf13
mv hugo hugo-0.16
GZIP=-9v tar cvzf hugo-0.16-full.tar.gz hugo-0.16

using govendor from https://github.com/kardianos/govendor.

[bep]

But I think we should just start do proper vendoring and this will be solved.

[anthonyfok]

Cc: @spf13

@ bep wrote:

But I think we should just start do proper vendoring and this will be solved.

Should we start by checking in vendor/vendor.json before the 0.16 release?
From https://github.com/kardianos/govendor/blob/master/doc/dev-guide.md:

Always check in the "vendor/vendor.json" file

You can add the ignore rule vendor/*/ to ignore source files. This way a consumer of your package has a chance at reproducing your package tests if something appears to break later.

I think this would remedy the sad situation where https://github.com/spf13/hugo/archive/v0.15.tar.gz quickly became almost impossible to compile (within a month?) due to API changes in upstream packages.

[bep]

Is that a standard vendoring format used by all the vendoring tools?

[anthonyfok]

Is that a standard vendoring format used by all the vendoring tools?

Good question, one that I hadn't thought of.

• Godep: Godeps/Godeps.json
• govendor: vendor/vendor.json
• gvt: vendor/manifest

So it looks like it differs among various vendoring tools.

[bep]

And then there is Dave Cheney's GDB ... We should pick one, but not by random.

[moorereason]

For reference see Go best practices, six years in: Dependency Management.

Random comments:

• There is no standard format for a dependency manifest file. The Go tools simply look for packages in /vendor.
• My vote is for govendor. Good feature set without being bloated. It has no files outside of the /vendor folder. I was able to vendor everything with govendor init && govender add +outside. Done. 👍
• If we are adding vendoring, I'd also like to stop using gopkg.in first. We can reference github.com/go-yaml/yaml@v2, removing the primary use case of gopkg.in.
• As much as I conceptually like GB, the deviation from the go tool chain complicates the development environment enough that I'd rather not have to support it in an open source project.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.