Thanks for accepting!

@av86743 the first error reported here:

env GO111MODULE= go get github.com/av86743/go-b0rken
go build github.com/av86743/go-b0rken: no non-test Go files in /home/ubuntu/go/src/github.com/av86743/go-b0rken

might be an instance of #29268 (comment). Does that seem related to the first error you reported here?

Aside from that, can you expand a bit on what you are attempting to do here?

For example, you say:

Repository 'github.com/av86743/go-leveldb' does not even exist

Could you expand on why you are using a repository that does not exist? For example, is this a simplified example of something else you saw?

@thepudds

@av86743 the first error reported here:

env GO111MODULE= go get github.com/av86743/go-b0rken
go build github.com/av86743/go-b0rken: no non-test Go files in /home/ubuntu/go/src/github.com/av86743/go-b0rken

might be an instance of #29268 (comment). Does that seem related to the first error you reported here?

Irrelevant, disregard this. It is just statement of a fact, it's not even tagged as an error.

Aside from that, can you expand a bit on what you are attempting to do here?

I am giving you a straight example where go.mod "replace" directive does not work. And registering your response.

For example, you say:

Repository 'github.com/av86743/go-leveldb' does not even exist

This is to bring your attention to the fact that compiler's error message reports a type from repository which does not even exist. How much sense does it make to you?

Could you expand on why you are using a repository that does not exist? For example, is this a simplified example of something else you saw?

Whether that repository exists or not, is immaterial - in the presence of "replace" directive for this repository. Don't you agree?

The replace directive replaces the source code for a module, not its import path (see #26904).

When you replace the package github.com/av86743/go-leveldb/leveldb, you end up loading the source code within github.com/syndtr/goleveldb/leveldb, and the files there import github.com/syndtr/goleveldb/leveldb/opt.

With the current semantics of replace, github.com/syndtr/goleveldb/leveldb/opt is a separate package from github.com/av86743/go-leveldb/leveldb/opt, even if they are built from source code in the same underlying repository. If github.com/syndtr/goleveldb is meant as a drop-in replacement for the source code of github.com/av86743/go-leveldb, then today it must use the original github.com/av86743/go-leveldb module and import paths.

We know that there is a use-case for replace to aid in un-forking modules that were previously forked, but we have not been able to address it yet. That's #26904 (and, to some extent, #30831).

Duplicate of #26904

@bcmills

The replace directive replaces the source code for a module, not its import path (see #26904).

When you replace the package github.com/av86743/go-leveldb/leveldb, you end up loading the source code within github.com/syndtr/goleveldb/leveldb, and the files there import github.com/syndtr/goleveldb/leveldb/opt.

With the current semantics of replace, github.com/syndtr/goleveldb/leveldb/opt is a separate package from github.com/av86743/go-leveldb/leveldb/opt, even if they are built from source code in the same underlying repository. If github.com/syndtr/goleveldb is meant as a drop-in replacement for the source code of github.com/av86743/go-leveldb, then today it must use the original github.com/av86743/go-leveldb module and import paths.

What do mean by saying "...it must use..." etc etc? github.com/syndtr/goleveldb is what it is. I have no control over its content.

The replace directive replaces the source code for a module, not its import path (see #26904).

When you replace the package github.com/av86743/go-leveldb/leveldb, you end up loading the source code within github.com/syndtr/goleveldb/leveldb, and the files there import github.com/syndtr/goleveldb/leveldb/opt.

With the current semantics of replace, github.com/syndtr/goleveldb/leveldb/opt is a separate package from github.com/av86743/go-leveldb/leveldb/opt, even if they are built from source code in the same underlying repository. If github.com/syndtr/goleveldb is meant as a drop-in replacement for the source code of github.com/av86743/go-leveldb, then today it must use the original github.com/av86743/go-leveldb module and import paths.

We know that there is a use-case for replace to aid in un-forking modules that were previously forked, but we have not been able to address it yet. That's #26904 (and, to some extent, #30831).

You could simply say: "@rsc solved it in https://golang.org/cl/174939 ." Thanks, in any case.

Cox rocks. Which also rhymes. Niccce, whichever way you look at it.

Note that CL 174939 isn't merged (and won't be for 1.13). There are some remaining issues with replacement semantics that we need to work out (described in a comment on the CL), and I'm planning to make another run at it for 1.14.

I've backported that CL (plus related changesets) to go1.12.5. It looks all right so far, but I need more time to validate typical use cases, review 5 items from CL which you mentioned, and just cool down a bit before I publish the port.