On Mon, 9 Mar 2020 at 19:59, Bartłomiej Płotka <[email protected]> wrote:
> 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. > Not an easy to debug record though, as you'd have to indirect through at least one other repo to figure out what changed. As I see it the costs are low, so there's no major reason to change things currently. Brian > > 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> >> . >> > -- 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/CAHJKeLqciD%2BtwZwcFPYxarHPwjQ2Ehs%2BZKfa30m2s1xWTmk3qg%40mail.gmail.com.
