I'd hope that the go build tools would treat the vendor directories as they do today -- one of the places to look for the dependencies you've included. So changing one to a go module would not affect the rest, and so we could add any new ones as modules.. It's not all-or-nothing, is it?
Dan On Thu, Jul 11, 2019 at 1:50 PM Rawlin Peters <[email protected]> wrote: > It might be possible to have some dependencies handled via the Go > module system and some with vendoring, but I haven't been able to find > any good information related to our specific situation (vendored > dependencies but without a tool like go dep managing them). It seems > like most of the information I've found assumes that if you're using > vendor directories that you must be using something like go dep, and > the go module system can "take over" your Gopkg.toml and track those > dependencies as part of the Go module system. So, I don't really know > what would happen if we tried to set up Go modules for new > dependencies. It would need to know about our vendor directories for > build purposes, but it wouldn't have any idea what version/commit hash > our dependencies are. > > Until we set up Go modules properly, we should probably at least save > the commit hash of any new dependencies we vendor into the repo and > try to vendor the latest SemVer-tagged release if we can. That would > make it easier to set up module versioning for those dependencies in > the future. > > - Rawlin > > On Thu, Jul 11, 2019 at 11:02 AM Fieck, Brennan > <[email protected]> wrote: > > > > Sure, no reason to change that right now. But with that in mind, would > > it be a problem for new dependencies to use the Go module system? > > ________________________________________ > > From: Rawlin Peters <[email protected]> > > Sent: Thursday, July 11, 2019 10:55 AM > > To: [email protected] > > Subject: Re: [EXTERNAL] Go dependency management > > > > 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 > > > > > > > > > >
