I circed some of the suggestions round my team. Sounds like others had already tried some of the suggestions with mixed results:
- Go v1.13 still has trouble authenticating to github without an "insteadof" in the config. We use 2FA on github, which seems to make HTTPS fail in a way that doesn't fall back to git+ssh mode? - Another team member said they tried using v0.0.0-00010101000000-000000000000 as version but it got replaced. On Thursday, October 24, 2019 at 10:35:32 AM UTC+1, Shaun Crampton wrote: > > >> The good news is that we're aware of (and planning to address) most of >> these pain points; the bad news is that we haven't been able to get to most >> of them yet. >> >> > Great to see, thanks! > > > >> >>> 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? 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. > > 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! > > > >> >> >> 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. > > >>> - 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. > > > >> >> We also just ran into the new GOPRIVATE env var and had to update all our >>> builds to use that. Couldn't that just fall back to the private behaviour >>> if it gets a cache miss, it seems over-engineered to require an explicit >>> exception! >>> >> >> The checksum database and proxy fallback are designed to provide >> integrity by default. >> >> Without making the opt-out explicit, an origin could serve one set of >> sources (and checksum) to you, and another version to someone else, and >> simply refuse to serve anything at all in response to queries from the >> checksum database (so that the entry would always be missing), and no one >> would be the wiser. >> > > > Fair enough, I suppose. From a selfish point of view, making the go > tooling auto-trust github.com private repos would be nice :-) I can't > easily do that with a single entry in GOPRIVATE since whether a repo is > private or not can only be guessed by whether you need to use credentials > or ssh to access it. > > > >> >> >> Another issue we've had is making a build mode where we can build against >>> local copies of the dependencies for quick development. We can add replace >>> directives to point to local directories, which is part of the puzzle, but >>> it's hard to do that "just for one build". Not sure what we're looking for >>> here; maybe an optional go.mod override file that can be passed in for just >>> one build? >>> >> >> You mean like https://golang.org/issue/34506? 🙂 >> >> >> > > Sounds like just what we need, thanks! > -- 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/930aff92-8600-4df1-8236-06b07916a57b%40googlegroups.com.
