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 <sylv...@abstraction.fr> wrote: > On Mon, 9 Mar 2020 at 16:54, Brian Brazil < > brian.bra...@robustperception.io> wrote: > >> On Mon, 9 Mar 2020 at 15:41, Julien Pivotto <roidelapl...@inuits.eu> >> wrote: >> >>> On 09 Mar 15:30, Brian Brazil wrote: >>> > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto <roidelapl...@inuits.eu> >>> 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 prometheus-developers+unsubscr...@googlegroups.com. >> 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 <sylv...@abstraction.fr> > > -- > 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 prometheus-developers+unsubscr...@googlegroups.com. > 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 prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYqGvZEpQFvMJ7scbXXqevq6DsZgTKtb4%3DS54iLT7KUUQ%40mail.gmail.com.
