I've been beating my head into this recently as well, and I'm not done yet so I can't say this works for sure, but the workaround appears to be a virtual Go repository in Artifactory. You would create a Go repository for github.com and another for <other repo>, then create a virtual repository on top of those which can map each specific repo path to the correct "real" repository within the virtual one.
You can also play tricks with .gitconfig rewriting rules to rewrite the actual fetches. You could do something like: git config --global url."<other repo.".insteadOf " https://github.com/poy/mock";, thereby redirecting the git fetch of mock to something which you control. These are big hammers which can break other things, though. On Mon, Mar 11, 2019 at 9:21 AM David Riley <fraveyd...@gmail.com> wrote: > 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. > -- 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.
