Removing Vendor

[Julien Pivotto]

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.

--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

[Brian Brazil]

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?

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).

--

Brian Brazil

www.robustperception.io

[Julien Pivotto]

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
> www.robustperception.io

[Brian Brazil]

On Mon, 9 Mar 2020 at 15:41, Julien Pivotto <roidel...@inuits.eu> wrote:

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'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.

--

Brian Brazil

www.robustperception.io

[Sylvain Rabot]

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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLqvvbvXvfMaDJomBM10hs2pLkiY6Q9fyuQZfo537b%2Bm6g%40mail.gmail.com.

--

Sylvain Rabot <syl...@abstraction.fr>

[Bartłomiej Płotka]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CADjtP1Fwqi_rn_27vZRgfUUwUj1QBGQeyPnVnZY8CHimtWcYvQ%40mail.gmail.com.

[Sylvain Rabot]

I wish I would have been able to write this argument.

Thanks Bartek.

--

Sylvain Rabot <syl...@abstraction.fr>

[Brian Brazil]

On Mon, 9 Mar 2020 at 19:59, Bartłomiej Płotka <bwpl...@gmail.com> 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

--

Brian Brazil

www.robustperception.io

[Bjoern Rabenstein]

On 09.03.20 19:59, Bartłomiej Płotka wrote:
>
> 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 (:

That's what the various go-modules proxies are for. And `go.sum` to
make sure that nobody is injecting modified code.

In my understanding, the main reason for the `vendor` directory is
that building from vendored sources in the `vendor` directory is an
officially supported feature (introduced in Go 1.11), which should be
kept working, at least for a while, to allow a smoother transition
from previous build workflows to the go-modules one.

From that perspective (and IMHO), the `vendor` directory can be
removed once most of the Prometheus community has fully embraced
go-modules. Personally, my main concern is that that's not so easy to
assess. The whole go-modules thing is not exactly uncontroversial even
in the Go community at large.

--
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

[Julien Pivotto]

As far as I know the main go proxies are maintained by google, and we
can not afford hosting one for the project in the long term. Google is
not really known for their long-term commitments.

I know that in the past we wanted to rebuild old releases of prometheus
and could not (for unrelated reasons!). If now (or in X years) the
goproxy decides to garbage collect dependencies untouched for x months
and the upstream is gone, rebuilding old releases will be even more
difficult.


My question about license check is still unanswered. I will ping CNCF
about this question, too.

>
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in

[Bjoern Rabenstein]

On 10.03.20 13:48, Julien Pivotto wrote:
>
> As far as I know the main go proxies are maintained by google, and we
> can not afford hosting one for the project in the long term. Google is
> not really known for their long-term commitments.
>
> I know that in the past we wanted to rebuild old releases of prometheus
> and could not (for unrelated reasons!). If now (or in X years) the
> goproxy decides to garbage collect dependencies untouched for x months
> and the upstream is gone, rebuilding old releases will be even more
> difficult.

There are plenty of non-Google-run go-modules proxy. And should Google
really shutdown hosting go-modules, I'm sure there will be even more.

And even if they all disappear, the git-hosting platforms that have
the source code can still give you the old versions of the source.

And even if they all disappear, you or me or somebody else will still
have a clone of the Git repo on their laptop.

In sum, I highly doubt that reconstructing the source code for an old
version will ever be impossible. It might be a bit inconvenient, but
the necessity of building old versions of Prometheus is rare enough
that it's not really of practical relevance. I would much prefer
leaner source repositories.

[Julien Pivotto]

Note: CNCF will adapt the tooling to support go.mod and go.sum so that
question is out of the table.

[Julius Volz]

I used to really care about keeping vendoring because it's the only way to make sure you really still have a copy of everything you need to build Prometheus no matter what dependency authors or hosts choose to do, but I guess the existence of module proxies and the fact that we also don't vendor "node_modules" (because that would be huge) is pushing me into the direction of caring less about it nowadays.

So I guess I don't mind either way now.

--
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.

[Bartłomiej Płotka]

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. (: 

Bartek

[Brian Brazil]

On Tue, 10 Mar 2020 at 16:46, Bartłomiej Płotka <bwpl...@gmail.com> wrote:

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. (: 

I'm not following your logic here, we currently already have a copy of the code sitting right there.

Brian

--

Brian Brazil

www.robustperception.io

[Sylvain Rabot]

Several maintainers have given their thoughts on the subjects now.

What would be the next step ?

Should this be put to a vote ?

Regards.

--
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.

--

Sylvain Rabot <syl...@abstraction.fr>

[Bjoern Rabenstein]

On 11.03.20 23:58, Sylvain Rabot wrote:
> Several maintainers have given their thoughts on the subjects now.
>
> What would be the next step ?
>
> Should this be put to a vote ?

We could.

My personal opinion is that if somebody commits to do the work of
changing our build processes to not use/have the `vendor` directory,
I'd be for it.

However, from the mail conversation and also from some personal
communication I had with a few team members, there are many who don't
really want to change the status quo right now, and some even prefer
to keep the `vendor` directory around.

Since the current state doesn't really block any other feature
development, and since the appetite for change doesn't seem to be very
high generally, I would say this is not super pressing at the moment,
and I wouldn't spin up the machinery of a formal vote for it right
now. It might, however, be a great topic to discuss at the next
developer summit. I have already added it to the agenda. (It was
planned to happen during KubeCon EU. Since the latter has been
postponed, we might do a virtual summit, but that's not finalized
yet.)

[Julien Pivotto]

After reading everything, I personally don't object to remove the vendor
directory. My personal gut is to keep it but there don't seem to be a
lot of good technical reasons to do so.

My very preferred choice would be to remove it but still to archive a
'vendor' directory within our CI process (next to the binaries?) to
ensure we still have the exact code around.

+1 to put it on the dev summit agenda.

[Bartłomiej Płotka]

I would love to have it removed, and in fact, I plan in my personal time to blog post and talk more about not storing someone else code in your own repository and why the vendor is (IMO) evil (: I hope also to help in any tooling that will fix the malicious dep problem without vendoring as well.

Anyway, I fully agree with Björn that there is no urgent need, so I don't have a strong opinion to fix this in Prometheus now, but anyway I would love to hear more opinions on the incoming DevSummit +1 Looks like thanks to Björn we already have that on our agenda.

Thanks for raising this Sylvain.

Kind Regards,

Bartek

--
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.

[Simon Pasquier]

As far as I'm concerned, I used to be in favor of vendoring. With Go
proxies being , I would be ok with removing it.
As others have said, there's no urgency though so let's discuss it
more in-depth at the DevSummit.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYMRzrpwWAZ4xGAzLp7jDdn1rHC%2B8Tb9vGuz6%2Bcrj4U%2BQ%40mail.gmail.com.

[Simon Pasquier]

(I've hit the Send button too fast so resending)

As far as I'm concerned, I used to be in favor of vendoring. With Go

proxies being a thing, I would be ok with removing it.

As others have said, there's no urgency though so let's discuss it
more in-depth at the DevSummit.