What version of Go are you using (go version)?

go version go1.10.2 linux/amd64 vgo:2018-02-20.1

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Linux

What did you do?

I've created some repos that are dependent on each other to reproduce the problem:

• github.com/JelteF/vgo-test-a
• github.com/JelteF/vgo-test-b
• github.com/JelteF/vgo-test-c
• github.com/JelteF/vgo-test-c-fork

The dependencies are as follows:

• A requires B
• B requires C
• B has a replace for C to C-fork (because C-fork has a fix for C)

Then I run the following in A:

vgo run main.go

What did you expect to see?

That it prints out:

correct

Which is what it would do if it uses the patched forked version of C

What did you see instead?

It prints out:

wrong

Which means it's using the unpatched version of C

Reasoning

A doesn't depend on a specific version of C. The only dependency requirements given for C are the ones given by B, so there's no reason not to fully go along with it.

Actual use case

I have this kind of situations happen when using the (non public) utils package that we have at my company. Sometimes one of it's dependencies need a fix or new feature and we want to use a fork temporarily while we wait for the fix to be merged. With dep this is easy right now by using the source attribute in the utils package Gopkg.toml and then update the utils package in all packages that use it. With vgo it seems to me that every package that depends on the utils packgae would need to add the replace to its own go.mod file. And after it is merged upstream we have to remove the replace everywhere again.

Some other related ideas

1. A similar thing seems true to me for an excludedetermined by a package when running vgo get -u. It would be nice if it would try to exclude those packages, so not every library user has to find out that the excluded version is incompatible with
2. If the MVS solver ignores a replace or exclude present in the go.mod of a library (e.g. because of conflicts), it would be nice if there was a warning stating that a replace/exclude that cannot be honoured. This way users have a much clearer path to fixing these kind of problems. I watched the GopherCon SG video, but the reasoning there doesn't apply when runnig vgo get -u. That still has the same problems as dep has, only there's no way for library authors to hint at a solution.
3. For the replace it might be nice if the replace from a library is honoured even if the module that it replaces is also in the go.mod of the root module (given that the version there is <= than the replaced one). The root module author would still need a way to override this decission though, but that could for instance be achieved by also specifying a replace.

(feel free to create new issues for these other ideas, they seemed related enough that I think it's nice to keep discussion in one place for now)

EDIT: I'm not saying to give vgo a full SAT solver, I would just like some changes to MVS to make it find the "correct" version in ~90% percent of the cases and give useful output for the developer in the complicated 10%.