Closed KateGo520 closed 3 years ago
Hi @KateGo520, we’re aware of this and tracking it in #71.
If you’ve got the domain knowledge to spare, I’d love to know how we can test a multi-module project with dependency version updates such as this one - in #76 I’m attempting to fix the issue where the command-line version can’t import the parent dependency because there isn’t a published version yet, but we don’t want to publish a version without also bumping the command-line version. Is there a way to get go with go modules enabled to treat our working copy as the repo for the purposes of resolving the v3 module?
Apparently this is still an issue - I can reproduce it with go 1.15.
On master, go.mod
no has the appropriate module suffix:
$ cat go.mod
module github.com/buildkite/terminal-to-html/v3
go 1.12
require github.com/urfave/cli v1.22.4
However, the latest tagged release (3.3.0) still has an incorrect module path in go.mod
:
https://github.com/buildkite/terminal-to-html/blob/v3.3.0/go.mod
Can we fix this for most users by tagged a 3.4.0 release with go.mod
fixed up?
I've published a v.3.4.0 release, which I believe fixes this issue.
I haven't retrospectively changed the earlier 3.x releases that are unusable when go modules are enabled - mutating the tags felt icky and ultimately not really necessary.
Thanks for your patience!
@yob
I bumped into this, and ran
❯ go get github.com/buildkite/terminal-to-html/v3
go: downloading github.com/buildkite/terminal-to-html/v3 v3.6.1
Which is dumped into ls ~/go/pkg/mod/github.com/buildkite/terminal-to-html/v3@v3.6.1/
but doesn't seem to include a binary? Is that normal?
I'm no golang expert, but I believe it's normal for there to be no binary after a go get
command.
Background
The
github.com/buildkite/terminal-to-html
uses Go modules and the current release version isv3
. And it’s module path is"github.com/buildkite/terminal-to-html"
, instead of"github.com/buildkite/terminal-to-html/v3"
. It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:Steps to Reproduce
GO111MODULE=on, run
go get
targeting any version >= v3.3.0 of thebuildkite/terminal-to-html
:run
go get github.com/buildkite/terminal-to-html
, the version will stuck in v3.2.0:SO anyone using Go modules will not be able to easily use any newer version of
buildkite/terminal-to-html
.Solution
1. Kill the go.mod files, rolling back to GOPATH.
This would push them back to not being managed by Go modules (instead of incorrectly using Go modules). Ensure compatibility for downstream module-aware projects and module-unaware projects projects
I see these dependencies in your go.mod file, which need modle awareness. So you'd better not use third-party tools(such as: Dep, glide, govendor…).
You also need to update the import path to:
2. Fix module path to strictly follow SIV rules.
Patch the
go.mod
file to declare the module path asgithub.com/buildkite/terminal-to-html/v3
as per the specs. And adjust all internal imports. The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).If you don't want to break the above repos. This method can provides better backwards-compatibility. Release a v2 or higher module through the major subdirectory strategy: Create a new v3
subdirectory
(github.com/buildkite/terminal-to-html/v3) and place a new go.mod file in that subdirectory. Themodule path
must end with/v3
. Copy or move the code into the v3 subdirectory. Updateimport statements
within the module to also use/v3
(import "github.com/buildkite/terminal-to-html/v3/…"). Tag the release withv3.x.y
.3. Suggest your downstream module users use hash instead of a version tag.
If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of
go get github.com/buildkite/terminal-to-html@version-tag
, module users need to use this following way to get thebuildkite/terminal-to-html
: (1) Search for thetag
you want (in browser) (2) Get thecommit hash
for thetag
you want (3) Rungo get github.com/buildkite/terminal-to-html@commit-hash
(4) Edit the go.mod file to put a comment about which version you actually used This will make it difficult for module users to get and upgradebuildkite/terminal-to-html
.*[]** You can see who will be affected here: [12 module users, e.g., kube-score/web, buildbarn/bb-browser, csweichel/werft] https://github.com/search?q=buildkite%2Fterminal-to-html+filename%3Ago.mod
Summary
You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.
For this issue,
Solution 2
can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.References