Thanks for the feedback. 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.
Detailed responses inline. On Tuesday, October 22, 2019 at 6:42:05 AM UTC-4, Shaun Crampton wrote: > > Hi All, > > My team own a large product that sprawls across a lot of repos. We also > manage a private, commercial fork and we occasionally do new development in > private and then merge across to open source. While a monorepo might have > been easier to manage, we're stuck with what we've got. We've recently > moved to go mod and it just seems like we're constantly fighting the tool. > I'm hoping you can either suggest some good workflows or maybe improve the > tool! > > 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. 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 > > > > This throws up a couple of problems: > > - What should version ??? be? It's only there to be replaced, which > seems like a bit of a smell. > - If I set it to the commit ID it gets resolved and I have to > change three places in the file each time I move the pin. > - If I set it to a particular version, that seems misleading. > - I guess I can set it to v0.0.0, but again that seems misleading. > > 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. > - 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). 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. 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? 🙂 -- 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/68003fda-f411-4e5f-9657-15b774c176d0%40googlegroups.com.
