|author||Russ Cox <firstname.lastname@example.org>||Mon Jun 25 22:08:48 2018 -0400|
|committer||Russ Cox <email@example.com>||Fri Jun 29 04:13:28 2018 +0000|
cmd/go/internal/modfetch: disable go.mod conversion for transitive deps Earlier dependency management tools (dep, glide, godeps, and so on) all wrote some kind of lock file saying which version of each dependency had been (or should be) copied into the vendor directory. When invoked in a new repo without a go.mod file, vgo can initialize go.mod by converting a lock file from one of those earlier systems. A key part of the design of Go modules (inherited from dep and others) is the automatic incorporation of constraints from dependencies into the top-level build, so that if A requires B, then A/go.mod and B/go.mod both have an effect on the versions chosen for A's build. Because of the auto-conversion, I thought of files like Gopkg.lock as being like "go.mod in different syntax", and so if A requires B and there's no B/go.mod but there is a B/Gopkg.lock, then the auto-converted B/Gopkg.lock gets used as if it were B/go.mod. On further consideration, this is too much to ask of the conversion. Stop. if A requires B, both have Gopkg.lock but not go.mod, and we're working in the repo for A, then it's fine to use A/Gopkg.lock to create an initial A/go.mod. If there are problems with the A/go.mod, we can edit that file to fix them. It's not fine to use B/Gopkg.lock to create an effective B/go.mod for use during the build. If there are any problems with the conversion in B, there is no way for us (working on A) to override it. Typical problems include: 1. Lock files that have not been properly pruned, resulting in spurious dependencies. 2. Module requirement cycles are impossible to express when using commit hashes as identifiers. Instead "tailspins" have been recorded instead. Because the lock files being used as the source for the auto-conversion all include transitive dependencies anyway, converting A/Gopkg.lock should suffice anyway. Move conversion code (still used for main module) out of modfetch into modconv. Change-Id: I45e33345a38a60f3c4a1eba166150ee1a66e5816 Reviewed-on: https://go-review.googlesource.com/120999 Reviewed-by: Bryan C. Mills <firstname.lastname@example.org>
This repository holds a prototype of what the go command might look like with integrated support for package versioning.
See research.swtch.com/vgo for documents about the design.
go get -u golang.org/x/vgo.
You can also manually git clone the repository to
This is still a very early prototype. You are likely to run into bugs. Please file bugs in the main Go issue tracker, golang.org/issue, and put the prefix
x/vgo: in the issue title.