Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: cmd/go: go get should support source archives #19614
This is a tester to see if there is any support for this idea. If there is then I will write up a more detailed proposal.
Currently the go get command expects to interact with a source control system to check out source code. There is no way to package up a source archive (e.g. tar or zip) and use go get to retrieve this.
This proposal would modify the go tool to look for a source archive according to a to-be-defined scheme when the user types
One possible strawman scheme would be to extend the
There are a number of advantages to using source archives:
I think this complexity can be avoided by stating that source archives are immutable.
To upgrade to a new version of a package, a new package path needs to be used, e.g.
Changing package-1.0.zip breaks the contract that source archives are immutable. The user would need to intervene and remove the old version manually. This is the same situation that occurs when getting from a vcs where the user has modified the local source and not committed it or the remote source has rebased the user's current commit out of existence. go get should not try and fix these problems.
I think saving the etag/sha256sum is out of scope of this change. I would expect the
I don't think that's a sufficient answer. Users are going to violate it anyway, either on purpose or by accident, and we need an answer to why two users have different results when one ran "go get" at time 1 and the other ran "go get" at time 2, then both ran "go get -u" and things were still different. We deal with enough of those support complaints already. This would make it worse. It's easy enough to say "just go rm -rf $GOPATH/src/foo", but in this case "foo" might be a far away dependency of the thing the user actually cared about.
In other words, we already support the "-u" flag. I don't think it's acceptable to just say that sometimes "-u" doesn't work for certain packages, seemingly randomly to the user.
As you pointed out on #16545 we don't want to implement a vcs system. If users want to modify their code in place and reuse the same package path then they should use the pre-existing go get support for common vcs systems. For source archives, versioning is achieved by naming the package paths and assuming the archive is immutable.
If there were a convention for locating a remote sha256sum then potentially we could add a way of verifying that the local source has the same hash as the remote but this is only informative.
I don't think it would appear to be at random. The user is typing in a package path that ends with
Immutability of source archives could be seen as a goal in of itself. The current mechanism for version pinning has confusing behaviour for end users. For example github.com/aktau/github-release uses semver to tag releases (and coincidentally is a tool for doing that). A user can pin a release by checking out a tag, e.g. cd $GOPATH/src/github.com/aktau/github-release; git checkout v0.5
Subsequent usages of go get -u result in a potentially confusing error:
This is made more confusing because the user believes they have just switched to the v0.5 "branch". Also
The source archive approach would retain the semantics of "pinning", guaranteeing that the source is unchanged, but continue to check and update dependencies (which may also be pinned).
No, I was referring to cases where the .zip is a dependency of something else.
Question: do User 1 and User 2 have the same code on disk? Will the
With your proposal, you no longer know. Because foo/bar might transitively depend on what you're assuming is an "immutable" package, but only because you're wishfully declaring that. A user could actually put