Well, I wasn't planning on tackling this right away -- I just wanted to bring it up and get some feedback for whenever I (or some other brave contributor) get the chance to do it. I'd lean towards doing it after the next release since I think we'd like to get another release out pretty soon, and I don't really know how long it will take. I think it's important that we do it for the sake of having good Go dependency management, but I don't think it's very urgent.
- Rawlin On Wed, Jul 10, 2019 at 11:13 AM Dave Neuman <[email protected]> wrote: > > This sounds like a good plan, but I wonder if this is something we want to > try to do before we cut the next release, or something we want to do > after? > > On Wed, Jul 10, 2019 at 10:31 AM Dan Kirkwood <[email protected]> wrote: > > > +1 > > > > On Wed, Jul 10, 2019 at 10:26 AM Fieck, Brennan <[email protected] > > > > > wrote: > > > > > +1 sounds fantastic to me > > > ________________________________________ > > > From: Rawlin Peters <[email protected]> > > > Sent: Tuesday, July 9, 2019 1:55 PM > > > To: [email protected] > > > Subject: [EXTERNAL] Go dependency management > > > > > > Hey all, > > > > > > Now that we've upgraded all our Go components to use v1.11, I believe > > > we can start using Go modules [1] to start managing our Go > > > dependencies for the project instead of vendoring our Go dependencies > > > directly into our repo. > > > > > > Does anyone have any experience using Go modules yet? After doing some > > > quick research on Go modules, I think we would just have to identify > > > the commit hash of each of our Go dependencies at the time they were > > > cloned into our repo and pin the versions of our dependencies to those > > > commit hashes in the go.mod file (since I believe the dependencies > > > were just cloned from the head of master and might not necessarily > > > line up with a SemVer release tag). > > > > > > I think these would be the steps (which could each be broken down into > > > multiple PRs if necessary): > > > Step 1: identify commit hashes of our current dependencies, implement > > > Go modules to manage them at our existing vendored versions, remove > > > the vendored code from the repo, and fix the build processes to use > > > the new Go module tooling. By the end of this step, the dependencies > > > we pull down for the build should match our existing vendored > > > dependencies exactly. > > > Step 2: reevaluate the current versions of our dependencies in order > > > to update them to compatible SemVer release tags provided by the > > > dependency (rather than a specific commit hash) if necessary. Once > > > pinned to specific SemVer versions, it should be easy to always keep > > > our Go dependencies up to date, although some dependencies might not > > > have implemented the required SemVer release tagging yet. > > > > > > Does this sound like a reasonable plan to everyone? I don't have any > > > experience using Go modules yet, so if anyone has experience with them > > > and has better ideas I'd love to get their input on this. Unless there > > > are any objections within the next few days, I'll assume everyone is > > > generally on board with Go modules, and someone could start working on > > > this after that time. > > > > > > Thanks, > > > Rawlin > > > > > > [1] > > > > > https://protect2.fireeye.com/url?k=5da6d7fab5a4c93e.5da6f04e-17c163f89d22e415&u=https://github.com/golang/go/wiki/Modules > > > > >
