On Thu, Oct 24, 2019 at 1:07 PM Shaun Crampton <sh...@tigera.io> wrote:
> 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? > > We have https://golang.org/issue/26232 open for 2FA workflows in general. In the meantime, you may need to configure a Personal Access Token <https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line> to get HTTPS to work. > - Another team member said they tried using > v0.0.0-00010101000000-000000000000 as version but it got replaced. > > That probably means that you have a higher version requirement from some other dependency. (The `go` command automatically updates the `go.mod` file to maintain consistency.) 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/Kg-X2qZQohg/unsubscribe. > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/golang-nuts/930aff92-8600-4df1-8236-06b07916a57b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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_Rbyir%2B%3Dpy_tNe_kzPTDBOQMfopO63PM%2B-g04ZPKERooQ%40mail.gmail.com.
