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 <julius.v...@gmail.com> 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 <roidelapl...@inuits.eu> > 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.
