@cstockton the issue here is similar to #25674 (comment).

At the time of writing, as you point out, the latest release of github.com/coreos/etcd is v3.3.7.

You will notice however that etcd has not yet been converted to being a Go module (no go.mod in the root of the repo, and no submodules). Hence for now we need to resort to an explicit vgo get:

cd `mktemp -d`
export GOPATH=$PWD
mkdir hello
cd hello
echo > go.mod
cat <<EOD > hello.go
package main // import "example.com/hello"

import (
        "fmt"

        "github.com/coreos/etcd/raft"
)

func main() {
        _ = raft.NewMemoryStorage()
        fmt.Println("Project compiled")
}
EOD
vgo get github.com/coreos/etcd@v3.3.7
vgo build

I'll close this for now because there is nothing untoward going on here, but please do shout if I've missed anything.

Thanks @myitcv, I'll give your suggestion a try in the future. I do feel like building projects has been solved for in the least common use case: a clean code base or projects that already use an existing package manager. Well we have 8 years of software out there today that was written without any of these things, I personally never moved to dep because of issues early on and I was waiting for the Go team to full buy into a solution. I feel as an end user experience, nothing could be better than giving the user a starting point of.. their current starting point. Then providing a sub command to take a path forward, this lets the user immediately migrate and start enjoying reproducible builds and slowly upgrade dependencies in a controlled way (at that point the version selection algorithms are really useful). Maybe I'm the minority though I don't know.

This means using a vgo migrate and a vgo update [--all, -a false] [pkg...] with either a vgo list or vgo update with a --dry-run flag. This covers the way I want to migrate to a new way of writing Go code, which is the way I want to migrate to a new way of literally anything. Small, measurable steps. Right now switching to vgo or dep means changing every single dependency which introduces failed compilations for a process that is unfamiliar to you. Far worst would be the cases when the upgrades allow compilation but introduce a production only bug, anyone first suspicion would be "vgo broke my code!" "it was working fine before vgo!".

Here is what would have been an amazing experience in my opinion:

cd $GOPATH/acme
vgo migrate
...
> wrote go.mod with:
> $GOPATH/src/... @vN.N.N # current tag I am using to build my project today.
> $GOPATH/src/... @e0e0e0 # current commit hash I am using to build my project today.

Now the first thing I am going to do is check for a reproducible build from a fresh checkout:

mkdir -p tmp/{,src} && cd tmp
export GOPATH=$(pwd)
cd src && git clone acme && cd acme && vgo build
# run my tests

Fantastic, now I have reproducible builds and I can work package upgrades into future sprints so I can spend dedicated time for big dependencies like etcd/raft are very critical to my system:

cd $GOPATH/src/acme
vgo update --dry-run github.com/coreos/etcd
> here's what will change if you go through with this:
>   etcd @ <tag>
>   dep1
>   dep2

Eventually my initial migration state will have caught up to what vgo is designed for and all is well. The experience would be seamless and pain free. I understand the caveats of checking the current work space, I get there is only so far you can go in some cases. Maybe repos that don't have git information in the vendor directory for example, could you still determine the version? Yes. Maybe not worth the compute cycles to do so though (iterate up / down comparing files and then hashes from closest revision matching the same set of files or something? not sure), but maybe it is.

Maybe this is unreasonable and I am a small minority, I know there is nothing stopping me from writing a tool that does this process and I just might do that. To be clear this isn't a proposal, consider it a detailed experience report from a decent sized internal project with >50 dependencies to maybe stir some thought. Thanks for the efforts spent on vgo thus far, I feel the entire Go ecosystem will benefit greatly once it is in wide spread use. I just hope the migration process becomes less painful, because the quicker everyone migrates the better the experience for everyone will be.