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.
On 09 Mar 15:30, Brian Brazil wrote:
> On Mon, 9 Mar 2020 at 15:26, Julien Pivotto <roidel...@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 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.
----Brian Brazil
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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLqvvbvXvfMaDJomBM10hs2pLkiY6Q9fyuQZfo537b%2Bm6g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CADjtP1Fwqi_rn_27vZRgfUUwUj1QBGQeyPnVnZY8CHimtWcYvQ%40mail.gmail.com.
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.
--
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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200310133729.GB22487%40oxygen.
Also, side note: In the event of some dependency disappearing we would need to get the old code (locally, other forks etc) anyway and fork it for long term usage ASAP for further development of Prometheus anyway, so I don't see how vendoring help here either. (:
--
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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200309152603.GA25698%40oxygen.
--
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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200312164709.GA21031%40oxygen.