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.

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-by: Bryan C. Mills <>
8 files changed
tree: 54e91141e6b71cae2ee13e19c729031ef7abedf7
  7. codereview.cfg
  8. main.go
  9. vendor/

Versioned Go Prototype (vgo)

This repository holds a prototype of what the go command might look like with integrated support for package versioning.

See for documents about the design.


Use go get -u

You can also manually git clone the repository to $GOPATH/src/

Report Issues / Send Patches


This is still a very early prototype. You are likely to run into bugs. Please file bugs in the main Go issue tracker,, and put the prefix x/vgo: in the issue title.

Thank you.