On Thu, Oct 24, 2019 at 5:36 AM Shaun Crampton <sh...@tigera.io> wrote:
> I think the biggest problem we have is when working with private repos. >>> What I want to express to the tool is >>> >>> My module requires commit abcd1234 (or version v1.2.3) of dependency >>> x/y/z >>> >>> Look for any instances of dependency x/y/z in git repo >>> g...@github.com:ourfork >>> instead of the default. >>> >>> >> I believe this is https://golang.org/issue/28176. >> >> It's an intriguing idea, but problematic if the dependencies are >> specified as pseudo-versions, because the commit hashes in a fork in >> general will not match the hashes in the upstream module. We're still >> exploring alternatives for this use-case. >> > > > So, the problem that pseudo-versions are trying to solve is ordering in > the face of unordered commit hashes? > Yes. For my use case, the way I want this to work is that, once a dependency is > pinned to my private fork, it's as if the public repo didn't exist. In 99% > of cases, all the pins that I'm working with are my organisation's repos > anyway so once we pin to a private fork that's what we want to use > everywhere, transitively, even in downstream repos. In extreme cases, even > the version numbering scheme in the private fork may be different so > there's not necessarily any relation between the open source v2.3.0 and the > private v2.3.0 tags. > In that case, you want a `replace` directive without a version on the left side. It will prune out more of your transitive dependency graph than is strictly necessary, but that's not usually a major problem. (I'm hoping we can offer something better in the future, but there isn't enough time for it to make 1.14.) Our minority use case is forking some public repo to make a fix. In that > case, a perfect tool would have a way to say "we need a version >= open > source version that must have (fix) commit abcd in its commit history" > Then, once our fix is upstreamed, the open source version will become a > candidate. I suspect that's too much to ask though! > If you expect the upstream fix to be accepted before the next patch release, generally the procedure there is: require example.com/some/dependency <current version> replace example.com/some/dependency <current version> => my.fork <some version> Then when you upgrade, you'll get a version higher than <current version> and your `replace` directive will no longer apply. If the patch doesn't come through, then you update <current version> in the `replace` directive and try again next time. However, what I can express to the tool is >>> >>> My module requires version ??? of dependency x/y/z >>> >>> Replace x/y/z @ version ??? with <other module> @ abcd1234 >>> >>> >>> >>> >> Currently it should be `v0.0.0-00010101000000-000000000000`. >> We're also rethinking this behavior for `replace` in general; see >> https://golang.org/issue/33370. >> > > Good to know that there's a good value to put there. Would be nice if it > could be made shorter, though, I'll have to look that up. > That's the version that the `go` command automatically inserts when it sees a `replace` directive without an explicit version. Ideally we shouldn't need to insert a version at all, though. >>> - There's nowhere to specify the details of the repo (e.g. >>> connection/auth type), all that has to magically work according to my git >>> settings and the defaults aren't great for private repos (which we access >>> over ssh). >>> >>> See https://golang.org/cmd/go/#hdr-Remote_import_paths. >> >> In general we expect that either you have an HTTPS server to locate the >> repo for a given import path (credentials can be stored in a `.netrc` file; >> see also https://golang.org/issue/26232), or you include an explicit VCS >> extension somewhere in the import path (and have corresponding credentials >> configured per-user in your VCS). >> > > Maybe I'm just out-of-date, go now tries git+ssh as well as https://, was > that new in v1.13? Since we only use github, that should be good enough > for me. > I'm not sure. I do know that 1.12 had a bug in its `.netrc` handling, which is fixed in 1.13 and might let you proceed past some step that failed previously. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKWVi_Qrk9aa39qje9nUkWHWXR0bCyuuvBtLJUW4aJhB_or-tw%40mail.gmail.com.
