Re: [prometheus-developers] Removing Vendor

2020-03-13 Thread 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.

On Fri, Mar 13, 2020 at 4:24 PM Simon Pasquier  wrote:
>
> 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.
>
> On Fri, Mar 13, 2020 at 1:42 PM Bartłomiej Płotka  wrote:
> >
> > 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
> >
> > On Thu, 12 Mar 2020 at 16:47, Julien Pivotto  wrote:
> >>
> >> On 12 Mar 17:42, Bjoern Rabenstein wrote:
> >> > 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.)
> >>
> >> 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.
> >>
> >> --
> >>  (o-Julien Pivotto
> >>  //\Open-Source Consultant
> >>  V_/_   Inuits - https://www.inuits.eu
> >>
> >> --
> >> 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/20200312164709.GA21031%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-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYMRzrpwWAZ4xGAzLp7jDdn1rHC%2B8Tb9vGuz6%2Bcrj4U%2BQ%40mail.gmail.com.

-- 
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/CAM6RFu5Y_MZyYXw-wEDehyM1TAWcpfCzBfuGe6Upmh65DPKPpQ%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

2020-03-13 Thread 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.

On Fri, Mar 13, 2020 at 1:42 PM Bartłomiej Płotka  wrote:
>
> 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
>
> On Thu, 12 Mar 2020 at 16:47, Julien Pivotto  wrote:
>>
>> On 12 Mar 17:42, Bjoern Rabenstein wrote:
>> > 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.)
>>
>> 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.
>>
>> --
>>  (o-Julien Pivotto
>>  //\Open-Source Consultant
>>  V_/_   Inuits - https://www.inuits.eu
>>
>> --
>> 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/20200312164709.GA21031%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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYMRzrpwWAZ4xGAzLp7jDdn1rHC%2B8Tb9vGuz6%2Bcrj4U%2BQ%40mail.gmail.com.

-- 
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/CAM6RFu5WBK4nJTgNKX%3D3q3eFNSq9VRpEixzUJ22%3DdfPRuFm5LA%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

2020-03-13 Thread 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

On Thu, 12 Mar 2020 at 16:47, Julien Pivotto  wrote:

> On 12 Mar 17:42, Bjoern Rabenstein wrote:
> > 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.)
>
> 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.
>
> --
>  (o-Julien Pivotto
>  //\Open-Source Consultant
>  V_/_   Inuits - https://www.inuits.eu
>
> --
> 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/20200312164709.GA21031%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYMRzrpwWAZ4xGAzLp7jDdn1rHC%2B8Tb9vGuz6%2Bcrj4U%2BQ%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

2020-03-12 Thread Julien Pivotto 
On 12 Mar 17:42, Bjoern Rabenstein wrote:
> 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.)

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.

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

-- 
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/20200312164709.GA21031%40oxygen.


signature.asc
Description: PGP signature

Re: [prometheus-developers] Removing Vendor

2020-03-12 Thread 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.)

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

-- 
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/20200312164200.GY14683%40jahnn.

Re: [prometheus-developers] Removing Vendor

2020-03-11 Thread 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.

On Mon, 9 Mar 2020 at 16:26, Julien Pivotto  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.
>
> --
>  (o-Julien Pivotto
>  //\Open-Source Consultant
>  V_/_   Inuits - https://www.inuits.eu
>
> --
> 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/20200309152603.GA25698%40oxygen
> .
>


-- 
Sylvain Rabot 

-- 
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/CADjtP1GOLZQ3-WM5GXJjaouCp0T_BUq%3DsueihUAyeEX6Pf31yA%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

2020-03-10 Thread Brian Brazil 
On Tue, 10 Mar 2020 at 16:46, Bartłomiej Płotka  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


>
> Bartek
>
> On Tue, 10 Mar 2020 at 16:37, Julius Volz  wrote:
>
>> 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.
>>
>> On Tue, Mar 10, 2020 at 2:37 PM Julien Pivotto 
>> wrote:
>>
>>> On 10 Mar 14:11, Bjoern Rabenstein wrote:
>>> > 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.
>>> >
>>> > --
>>> > Björn Rabenstein
>>> > [PGP-ID] 0x851C3DA17D748D03
>>> > [email] bjo...@rabenste.in
>>>
>>> Note: CNCF will adapt the tooling to support go.mod and go.sum so that
>>> question is out of the table.
>>>
>>> --
>>>  (o-Julien Pivotto
>>>  //\Open-Source Consultant
>>>  V_/_   Inuits - https://www.inuits.eu
>>>
>>> --
>>> 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/20200310133729.GB22487%40oxygen
>>> .
>>>
>>

-- 
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/CAHJKeLrNxz%3DthSp5ij8CkUkAtgTi61rvjMObkcxfO3VW2BjbhA%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

2020-03-10 Thread 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

On Tue, 10 Mar 2020 at 16:37, Julius Volz  wrote:

> 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.
>
> On Tue, Mar 10, 2020 at 2:37 PM Julien Pivotto 
> wrote:
>
>> On 10 Mar 14:11, Bjoern Rabenstein wrote:
>> > 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.
>> >
>> > --
>> > Björn Rabenstein
>> > [PGP-ID] 0x851C3DA17D748D03
>> > [email] bjo...@rabenste.in
>>
>> Note: CNCF will adapt the tooling to support go.mod and go.sum so that
>> question is out of the table.
>>
>> --
>>  (o-Julien Pivotto
>>  //\Open-Source Consultant
>>  V_/_   Inuits - https://www.inuits.eu
>>
>> --
>> 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/20200310133729.GB22487%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAMssQwaDaPE%2BKYvnUpQrKwG8sPdXS5uRX32B7XMXp8LtTvM1_A%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

2020-03-10 Thread 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.

On Tue, Mar 10, 2020 at 2:37 PM Julien Pivotto 
wrote:

> On 10 Mar 14:11, Bjoern Rabenstein wrote:
> > 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.
> >
> > --
> > Björn Rabenstein
> > [PGP-ID] 0x851C3DA17D748D03
> > [email] bjo...@rabenste.in
>
> Note: CNCF will adapt the tooling to support go.mod and go.sum so that
> question is out of the table.
>
> --
>  (o-Julien Pivotto
>  //\Open-Source Consultant
>  V_/_   Inuits - https://www.inuits.eu
>
> --
> 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/20200310133729.GB22487%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YozyjabDDVJ-M7EWM-rF%3D8-47iPS5oeQD1Tt6wawN5mTWg%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

2020-03-10 Thread Julien Pivotto 
On 10 Mar 14:11, Bjoern Rabenstein wrote:
> 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.
> 
> -- 
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in

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

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

-- 
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/20200310133729.GB22487%40oxygen.


signature.asc
Description: PGP signature

Re: [prometheus-developers] Removing Vendor

2020-03-10 Thread 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.

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

-- 
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/20200310131122.GO14683%40jahnn.

Re: [prometheus-developers] Removing Vendor

2020-03-10 Thread Julien Pivotto 
On 10 Mar 13:41, Bjoern Rabenstein wrote:
> 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.

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

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

-- 
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/20200310124818.GA12158%40oxygen.


signature.asc
Description: PGP signature

Re: [prometheus-developers] Removing Vendor

2020-03-10 Thread 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

-- 
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/20200310124142.GL14683%40jahnn.

Re: [prometheus-developers] Removing Vendor

2020-03-09 Thread Brian Brazil 
On Mon, 9 Mar 2020 at 19:59, Bartłomiej Płotka  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  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 
>>> wrote:
>>>
 On 09 Mar 15:30, Brian Brazil wrote:
 > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
 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 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

Re: [prometheus-developers] Removing Vendor

2020-03-09 Thread Sylvain Rabot 
I wish I would have been able to write this argument.

Thanks Bartek.

On Mon, 9 Mar 2020 at 20:59, Bartłomiej Płotka  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.
>
> 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  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 
>>> wrote:
>>>
 On 09 Mar 15:30, Brian Brazil wrote:
 > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
 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 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
>>>

Re: [prometheus-developers] Removing Vendor

2020-03-09 Thread 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

On Mon, 9 Mar 2020 at 18:19, Sylvain Rabot  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 
>> wrote:
>>
>>> On 09 Mar 15:30, Brian Brazil wrote:
>>> > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
>>> 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 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
>> 
>> .
>>
>
>
> --
> Sylvain Rabot 
>
> --
> You received this message because you are subscribed to the

Re: [prometheus-developers] Removing Vendor

2020-03-09 Thread Sylvain Rabot 
On Mon, 9 Mar 2020 at 16:54, Brian Brazil 
wrote:

> On Mon, 9 Mar 2020 at 15:41, Julien Pivotto 
> wrote:
>
>> On 09 Mar 15:30, Brian Brazil wrote:
>> > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
>> 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 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
> 
> .
>


-- 
Sylvain Rabot 

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

Re: [prometheus-developers] Removing Vendor

2020-03-09 Thread Brian Brazil 
On Mon, 9 Mar 2020 at 15:41, Julien Pivotto  wrote:

> On 09 Mar 15:30, Brian Brazil wrote:
> > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
> 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 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

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

Re: [prometheus-developers] Removing Vendor

2020-03-09 Thread Julien Pivotto 
On 09 Mar 15:30, Brian Brazil wrote:
> On Mon, 9 Mar 2020 at 15:26, Julien Pivotto  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 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

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

-- 
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/20200309154120.GA365%40oxygen.


signature.asc
Description: PGP signature

Re: [prometheus-developers] Removing Vendor

2020-03-09 Thread Brian Brazil 
On Mon, 9 Mar 2020 at 15:26, Julien Pivotto  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 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

-- 
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/CAHJKeLpKHBWC2NkrSofMqTY9iP%3DB6j2j2%2B-Sb0kSCt%3Drm8s-zA%40mail.gmail.com.