That's true. The vgo importer is only trying to do a good job with the basic cases, not capture all the complexity possible in a Gopkg.lock. @sdboyer is planning to write a more advanced standalone converter for this kind of case.

Change https://golang.org/cl/120075 mentions this issue: cmd/go/internal/modconv: support conversion preserves replace and exclude statement

We've dropped the plans for the standalone converter - the go command does a good enough job that we should just fix whatever is left that it can handle but doesn't. (Many things in Gopkg.toml it can't handle, and that's OK too.)

We should look into making cmd/go/internal/modconv handle the example in this report directly, though. Repurposing this issue.

Maybe I can work on this, @rsc.

@oiooj That'd be great, thanks.

Change https://golang.org/cl/126915 mentions this issue: cmd/go/internal/modconv: support convert replacements in Gopkg.lock

@oiooj - thanks for picking this up! A question - would your versions of ParseGopkgLock (modconv/dep.go) be able to handle source directives such as source = "git@internal.mirror.company.com:google/go-github.git"? Here's the full snippet from our Gopkg.lock:

[[projects]]
  branch = "customfix"
  name = "github.com/google/go-github"
  packages = ["github"]
  revision = "7f787a673ce7e986ecc98b1925c90369e1a3b372"
  source = "git@internal.mirror.xyzcompany.com:google/go-github.git"

corresponding part from Gopkg.toml is:

[[constraint]]
  name = "github.com/google/go-github"
  branch = "customfix"
  source = "git@internal.mirror.xyzcompany.com:google/go-github.git"

Currently running go1.11beta3 mod init gives an error:
go: converting Gopkg.lock: stat github.com/google/go-github@7f787a673ce7e986ecc98b1925c90369e1a3b372: unknown revision7f787a673ce7e986ecc98b1925c90369e1a3b372 - possibly because the revision 7f787a673ce7e986ecc98b1925c90369e1a3b372 is the commit hash for the customfix branch in the internal fork, not present in the upstream repo. If this is something that you intend to fix, I'd be happy to test your version.

@dmitris Thanks for your reminding, the change updated and this change not yet merged in the master.

I see that @bcmills made last comments on Sep. 11 on https://go-review.googlesource.com/c/go/+/126915 - @oiooj do you plan to address them / update the patch? If you could use some help with getting the change to the merge, let me know, I may be able to spend some time on this. (I'm interested in this since we would like to convert a large number of Gopkg.lock files to go.mod - with all the "third party" imports sourced from the internal mirror - and doing it manually is very tedious and time-consuming.)

@bcmills This still has the 1.12 milestone. Is it still being considered for 1.12? Seems to be a reasonably popular request that would help smooth out migration for some people.

This has a CL from @oiooj that came in before the freeze, but of course we are deep into beta at this point, so I'm guessing it is 'no', but wanted to at least bounce the issue. (Separately, @dmitris also attempted an alternative fix in #25556).

This isn't going to land for 1.12, sorry — the review slipped off my radar.

We should try to have consistent replacement support (this and #25556) for 1.13.

Hi,

Another test case maybe.

Looking here, that override is about a case where the original package (github.com/opencontainers/image-tools) has a bug that upstream can't / won't fix and there's a forked version with the fix at https://github.com/sylabs/image-tools.

[[override]]
  branch = "master"
  name = "github.com/opencontainers/image-tools"
  source = "https://github.com/sylabs/image-tools"

The resulting Gopkg.lock section looks like this:

[[projects]]
  branch = "master"
  digest = "1:424b050a94341c4f95826c0b5b00df12d2fdb367250989b551c586525d1a43ee"
  name = "github.com/opencontainers/image-tools"
  packages = ["image"]
  pruneopts = "UT"
  revision = "2814f498056809a9d5baaf76d1d82312180a5888"
  source = "https://github.com/sylabs/image-tools"

run a test with go built from the version of https://go-review.googlesource.com/c/go/+/126915 rebased on top of master. The input were the following Gopkg.toml and Gopkg.lock files based on an internal project (obfuscated some names and paths):

Gopkg.toml:

[[constraint]]
  name = "github.com/pkg/errors"
  source = "git.companyxyz.com/ghmirror/pkg--errors"
  version = "0.8.1"

[prune]
  go-tests = true
  unused-packages = true

Gopkg.lock:

# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.


[[projects]]
  digest = "1:ec23944b1218b31d1ea720eba74687d089771868430eeb3c8db5eadcd8fcbeb7"
  name = "git.companyxyz.com/orgfoo/repobar"
  packages = ["."]
  pruneopts = "UT"
  revision = "494e59d3d3767efc1f3b0ec1f558c2376eb0cc45"
  version = "v1.4.4"

[[projects]]
  digest = "1:cf31692c14422fa27c83a05292eb5cbe0fb2775972e8f1f8446a71549bd8980b"
  name = "github.com/pkg/errors"
  packages = ["."]
  pruneopts = "UT"
  revision = "ba968bfe8b2f7e042a574c888954fccecfa385b4"
  source = "git.companyxyz.com/ghmirror/pkg--errors"
  version = "v0.8.1"

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  input-imports = [
    "git.companyxyz.com/orgfoo/repobar",
    "github.com/pkg/errors",
  ]
  solver-name = "gps-cdcl"
  solver-version = 1

The output was a go.mod file with the expected replace line: replace github.com/pkg/errors v0.8.1 => git.companyxyz.com/ghmirror/pkg--errors v0.8.1.

go.mod:

module git.companyxyz.com/orgfoo/repobar

go 1.13

require (
	git.companyxyz.com/orgfoo/repobar v1.4.4
	git.companyxyz.com/ghmirror/pkg--errors v0.8.1
)

replace github.com/pkg/errors v0.8.1 => git.companyxyz.com/ghmirror/pkg--errors v0.8.1

Based on this test, the patch seems to work as advertised and it would be great to get it in the go1.13 release.