diff: latest release version still has old module path

[dmitshur]

The import path of this package has changed in PR #30. /cc @sqs

However, the latest released version (v0.5.0) still has the old module path in its go.mod file:

https://github.com/sourcegraph/go-diff/blob/v0.5.0/go.mod#L1

As a result, trying to install the latest version of this package in module mode fails:

$ cd $(mktemp -d)

$ go mod init m
go: creating new go.mod: module m

$ go get github.com/sourcegraph/go-diff/diff
go: finding github.com/sourcegraph/go-diff/diff latest
go: github.com/sourcegraph/[email protected]: parsing go.mod: unexpected module path "sourcegraph.com/sourcegraph/go-diff"
go: error loading module requirements

$ echo $?
1

This can be fixed this by making a new release version (perhaps v0.5.1) that contains the new module path in the go.mod file.

[sqs]

Thanks for reporting this. I just pushed v0.5.1.

xq:~/src/sourcegraph.com/sourcegraph/go-diff $ cd $(mktemp -d)
xq:/tmp/tmp.1x6ATreARY $ go mod init m
go: creating new go.mod: module m
xq:/tmp/tmp.1x6ATreARY $ go get github.com/sourcegraph/go-diff/diff
go: finding github.com/sourcegraph/go-diff/diff latest
go: finding github.com/sourcegraph/go-diff v0.5.1
go: downloading github.com/sourcegraph/go-diff v0.5.1
go: extracting github.com/sourcegraph/go-diff v0.5.1

[dmitshur]

Thanks for the quick fix.

[ppapapetrou76]

Hey @sqs I think it's still happening on 0.5.1
go: sourcegraph.com/sourcegraph/[email protected]: parsing go.mod: unexpected module path "github.com/sourcegraph/go-diff"

If I set the module dependency to direct like this github.com/sourcegraph/go-diff v0.5.1 before the module that has a dependency to it it's fine

[dewey]

@ppapapetrou76 as you said you have an indirect dependency it's probably some dependency of yours that pulls go-diff in with a wrong import path. In this case you could rewrite the path to the new one in your go.mod file like:

go mod edit -replace sourcegraph.com/sourcegraph/go-diff@latest=github.com/sourcegraph/go-diff@latest

[ppapapetrou76]

Indeed the root cause it's here golangci/golangci-lint#487 😄
I will apply your suggestion while waiting for the PR merge

TY!!

[sqs]

Sorry for the problems caused, @ppapapetrou76. Just checking, it sounds like your problem is solved (or wil be solved when that PR is merged), right?

[rameshvk]

I did the replace trick suggested before and now I get:

go: github.com/sourcegraph/[email protected] used for two different module paths (github.com/sourcegraph/go-diff and sourcegraph.com/sourcegraph/go-diff)

Not really looking for a resolution as the large set of issues I faced with go mod have convinced me to abandon go.mod until after it matures and is well supported. This is mostly to note that the replace trick may not always work.

[dmitshur]

@rameshvk Sorry to hear you've had a bad experience with modules. If you'd like, feel free to /cc me on an issue in the repository where you ran into the problem with more information, and I can take a look. Perhaps it's been fixed for Go 1.13 already, and if not, we want to make sure it does.

The summary of the situation here is that version v0.5.0 of go-diff can only be used at the module path sourcegraph.com/sourcegraph/go-diff, and versions v0.5.1 (and newer) can only be used at the module path github.com/sourcegraph/go-diff (because that's the version where its module path changed).

The following replace directive can be used in the main module to replace any incorrect module versions (in dependencies that haven't been updated yet) with a working one:

replace sourcegraph.com/sourcegraph/go-diff => sourcegraph.com/sourcegraph/go-diff v0.5.0

And/or:

replace github.com/sourcegraph/go-diff => github.com/sourcegraph/go-diff v0.5.1

[rameshvk]

Doing that replace gives me this error:

go: errors parsing go.mod: go.mod:63: replacement module without version must be directory path (rooted or starting with ./ or ../)

I also tried cloning the package locally (which is actually what I'd prefer) but that had a different set of errors.

I find that most issues I run into have been reported (like this) -- it is just that the set of workarounds does not seem like things I can maintain. I suspect when all upstream packages migrate to go.mod, much of my pain will go away and I can then migrate over too.

[dmitshur]

My mistake, I didn't test the exact replace directive I suggested. Updated my post above to provide a better suggestion.

@rameshvk Can you point me to a repository and a command I can run to reproduce your original problem? It'll be easier to diagnose this with more information.

That said, you're right, the experience should improve over time. Still, I'm happy to help with your problem if you'd like.

[rameshvk]

Thanks for your help, that does work (though its not clear to me why go mod -replace wont do a blanket replace as that itself is a useful feature)

The repository I'm migrating is a dep of testmd and the only reason I'm migrating this is because I get an error downstream:

	imports github.com/tvastar/test
	imports gopkg.in/russross/blackfriday.v2: unknown import path "gopkg.in/russross/blackfriday.v2": cannot find module providing package gopkg.in/russross/blackfriday.v2
gopkg.in/russross/blackfriday.v2

I figured upgrading this to go.mod might help. Your help (thanks!) unblocked one issue but next up is that golangci-lint has an issue (which has been fixed but not released yet). I suppose I could go get a particular commit from golangci-lint but doing so seems to pollute my go.mod with package versions that are not tied to actual code dependencies but lint-tool dependencies. I wish I could just download all the things I need and commit them (sort of like vendor but with guarantees that build would break rather than auto-download something).

[VojtechVitek]

Looks like the underlying go get CLI issue has been discussed in the Go issue tracker too: golang/go#30831 (comment). Hopefully it'll be fixed soon.

For anyone interested, you can apply this workaround (as suggested by Dmitri above):

replace (
	// https://github.com/sourcegraph/go-diff/issues/33
	github.com/sourcegraph/go-diff => github.com/sourcegraph/go-diff v0.5.1
	sourcegraph.com/sourcegraph/go-diff => github.com/sourcegraph/go-diff v0.5.1
)

Or find the indirect dependency that pulls in the v0.5.0 and update it. In our case, we had to update cloud.google.com/go v0.36.0 to a newer version.

[rameshvk]

Without transitive build constraints (such as in golang/dep#1124), the workarounds proposed here would need to be applied by every downstream dependency. Or am I missing something?

[dmitshur]

the workarounds proposed here would need to be applied by every downstream dependency.

That's correct. The act of changing an import path (issue #27) means every active downstream dependency needs to be updated to start using the new import path, or never update to newer versions via go get -u.

There's something that can be done on Sourcegraph's end to reduce toil for all downstream dependencies using the module mode. Right now the vanity import path serves a single go-import meta tag at https://sourcegraph.com/sourcegraph/go-diff?go-get=1:

<meta name="go-import" content="sourcegraph.com/sourcegraph/go-diff git https://github.com/sourcegraph/go-diff">

It can add a second go-import meta tag that uses the "mod" VCS type and point to a module proxy that serves the sourcegraph.com/sourcegraph/go-diff module with just the v0.5.0 version, not v0.5.1 or newer (since those have a github.com/sourcegraph/go-diff module path). That way, downstream users who are still using the old "sourcegraph.com/sourcegraph/go-diff" import path will not see errors when doing go get -u, since v0.5.0 will be considered the latest version available.

However, there are two problems with that:

1. it adds complexity and more things to maintain, which is counter to the goal of removing the vanity import path as described in issue Remove sourcegraph.com vanity import path #27
2. it's too late to do this now, because some users and module proxies may have already cached sourcegraph.com/sourcegraph/[email protected] module version, so it may continue to exist if those proxies are used. For example, proxy.golang.org already has v0.5.1 cached, see here.

It would've been a better idea to consider at the time of changing the import path, but it's less useful to do it afterwards. I wrote this up for posterity, since this is a strategy that can be used in future for less disruptive import path changes.