Hi all, We're running into a bit of an interesting problem with modules. A month or two ago, we finally converted our project over to using modules, partly because it was The Right Thing To Do and partly because Artifactory supports module repositories (but not dep).
The process hasn't exactly been a smooth one. We've hit a few of the interesting corner cases with modules, but none of them has been quite so pesky as the issue of replacing broken upstream dependencies with private forks. The one that's giving us the most trouble is the mock package (github.com/golang/mock); as-is, it does not support Go Modules because the stock "mockgen" executable generates code which uses relative imports, which do not work under modules. There is a fix in review for this from github.com/poy/mock, but it's been held up because the only viable fix would break Go 1.9 and below, and the author was waiting for the release of 1.12 so that 1.9 would drop from the support list. 1.12 has been released, and the fix is lingering in review (it's https://github.com/golang/mock/pull/253 if anyone is curious). Anyway, we absolutely require mockgen for our build and tests, and so we used a "replace" line in our go.mod file to point at the "poy" repo's "go-modules" branch. That fixed the problem, but caused other ones for two reasons: 1) force-pushes were being used to rebase changes onto the branch, which caused the old commits to disappear and break the build, and 2) modules can't track a branch head, they can only be pointed at specific commits based on a ref when they're first pulled. So we made a private fork of the repository at a point where it was functioning properly, which has solved THOSE problems for the time being. However, we can't get it to be cached in Artifactory's private repo (we cannot use the transparent proxy mode for Reasons) because the go.mod file in the fork claims it is github.com/golang/mock instead of <other repo>/mock. This doesn't cause problems with Go, which is happy to use it as a replacement, but Artifactory won't store it (and in fact barfs if I try to add it as a direct dependency because of the mismatch). This means we can't build with GOPROXY set to the Artifactory repo, because the replacement module doesn't exist there and there's no fallback mechanism for GOPROXY, so the build just fails at the initial "go mod download". Is there a good solution to this conundrum that isn't a) vendoring, which is yucky, or b) rewriting go.mod in the private fork? This sort of situation is inevitably going to happen again when we need to make private fixes to a dependency or the like, and it would be good to know if there's either a de facto or de jure best practice for this. I recognize that this is probably a deficiency in Artifactory's module handling code (it doesn't seem to understand the "replacement" concept), and while I also recognize that this isn't an Artifactory support list, I have to imagine that someone here has run into this problem (or a similar one). Thanks in advance. - Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
