Unpopular opinion: IMO vendoring can be long term a really bad pattern. The go.mod, go modules or any other dependency management tool or dep caching (e.g GOPROXY) was created *exactly* to avoid copying all the dependencies to your repository. (:
So I would be happy to remove vendor dir and work towards safe caching dependencies in some other repository, GOPROXY etc. > I'm talking about vendoring in general. We'd want a good reason to change our build system in this way, and I'm not aware of any reason why we'd want to change this with our current build system. *Fair. Would be nice to enumerate the downsides:* * We update deps mostly when adding some feature etc. This means usually us being lazy and doing feature code + committing thousands of files. Fun to review. Splitting by commit does not really help. Rarely we review like this and still it's super noisy, it's easy to miss a meaningful change in our codebase hidden among 300k lines of codes. ): * Repo size dramatically larger. Cloning etc operations e.g. CI checkout. * Git stats totally malformed (lines changed). * We host in our repo **not our code**. > Having it locally is handy for debugging, and it means we at least have a copy and a clear record of what changed when. It also more easily allows for local development. I don't get it. go.mod and go.sum are versioned so those already give the clear record. For local development `go mod vendor` locally is a one-off step (local vendor will keep being updated for lifetime of your local repo), so I don't any problem with this. I think the main argument for having a vendor folder is to be safe on a malicious act of dependency actor, which removes or compromises the dependency. Anyone can replace the code for a given tag anytime really (: Given that it never happened, not sure if worth pursuing. Wonder why no one thought about some separate repo solution just for deps then (: Bartek On Mon, 9 Mar 2020 at 18:19, Sylvain Rabot <[email protected]> wrote: > On Mon, 9 Mar 2020 at 16:54, Brian Brazil < > [email protected]> wrote: > >> On Mon, 9 Mar 2020 at 15:41, Julien Pivotto <[email protected]> >> wrote: >> >>> On 09 Mar 15:30, Brian Brazil wrote: >>> > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto <[email protected]> >>> wrote: >>> > >>> > > Hi there, >>> > > >>> > > Sylvain has open a pull request to remove the vendor directory. We >>> had >>> > > larger threads before on versioning etc, but I would like to start a >>> new >>> > > thread about this particular topic to see if we have a consensus. >>> > > >>> > > https://github.com/prometheus/prometheus/pull/6949 >>> > > >>> > > One of the blocker I have is that I would like to be 100% sure that >>> the >>> > > checks that are run by CNCF on licence compatibility have full >>> support >>> > > for this, e.g. they can fetch the modules and scan the licenses. >>> > > >>> > >>> > The question here is that as this is all internal, does this make >>> sense for >>> > our build&review processes? >>> >>> >>> Can you clarify the question. Are you speaking about removing vendoring >>> or license check? >>> >> >> I'm talking about vendoring in general. We'd want a good reason to change >> our build system in this way, and I'm not aware of any reason why we'd want >> to change this with our current build system. >> > >> >>> > I don't recall offhand anyone in -team having issues with our current >>> state >>> > (beyond a brief discussion if we still wanted it when we switched to >>> go-mod >>> > - we do). >>> >>> I am all for keeping vendor but I have not really strong arguments >>> against removing it. >>> >>> I often use it to grep some dependencies sources but I could still run >>> go mod vendor locally. >>> >> >> Having it locally is handy for debugging, and it means we at least have a >> copy and a clear record of what changed when. It also more easily allows >> for local development. >> > > I personally don't have any trouble doing any of that without vendoring. > > Also, it's much easier to keep track of what happened to the dependencies > in the history of the go.mod than in the vendor/ dir. > > I admit it can be handy to grep in the vendor/ dir although I personally > hate it when I'm looking for something and I get submerged by results in > the vendor/ dir. > > >> -- >> Brian Brazil >> www.robustperception.io >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Prometheus Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLqvvbvXvfMaDJomBM10hs2pLkiY6Q9fyuQZfo537b%2Bm6g%40mail.gmail.com >> <https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLqvvbvXvfMaDJomBM10hs2pLkiY6Q9fyuQZfo537b%2Bm6g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Sylvain Rabot <[email protected]> > > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CADjtP1Fwqi_rn_27vZRgfUUwUj1QBGQeyPnVnZY8CHimtWcYvQ%40mail.gmail.com > <https://groups.google.com/d/msgid/prometheus-developers/CADjtP1Fwqi_rn_27vZRgfUUwUj1QBGQeyPnVnZY8CHimtWcYvQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYqGvZEpQFvMJ7scbXXqevq6DsZgTKtb4%3DS54iLT7KUUQ%40mail.gmail.com.
