+1 On Thu, Jul 11, 2019 at 10:55 AM Rawlin Peters <[email protected]> wrote:
> 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 > > > > > > > > -- Thanks and Regards, Lavanya Bathina 303-676-7825
