For what it's worth I've just started a fresh topic <https://groups.google.com/forum/#!topic/prometheus-developers/DY88o6yOg28> with my first results using the modularise tool.
On Fri, 28 Feb 2020 at 13:23, Sylvain Rabot <[email protected]> wrote: > Ok so I've been talking to Duco about this and he convinced me that using > in repo replace directives with relative paths is not a good idea. > > If he has the time he can explain it much better than I could. > > On Fri, 28 Feb 2020 at 12:04, Sylvain Rabot <[email protected]> > wrote: > >> After giving it more search, it came to (my) light that go mod handles >> "special" git tags for go mod sub-versioning. >> >> >> https://github.com/golang/go/wiki/Modules#what-are-multi-module-repositories >> >> The tag for version 1.2.3 of module "my-repo/foo/rop" is "foo/rop/v1.2.3". >>> >> >> I.E, "go get github.com/prometheus/prometheus/tsdb/[email protected]" would >> resolve "github.com/prometheus/prometheus.git" at tag "tsdb/v2.13.0" >> >> With that in mind, I believe having multiple independent go modules in >> the same git repo is OK. >> >> With this we can leverage the initial reason of having those "core" >> modules inside prometheus/prometheus (no sync overhead) and a decent >> independent development oriented life cycle. >> >> We currently have release shepherds, I think that if we were to implement >> this, we would need a shepherd per module responsible for releasing >> versions of "his" module(s). >> >> I made a Draft PR to get a sense of it: >> https://github.com/prometheus/prometheus/pull/6888/commits/44149825edb0b5c92885f362b6f3ae1643e2f451 >> >> It's pretty light if we exclude removing vendoring altogether (because I >> don't believe vendoring makes sense anymore with the latest versions of go >> and because each module having its own go mod needs its own vendor/ dir). >> >> The only problem I encountered came from promu. In the case we want to >> build a binary in a module that has its own go.mod file (like tsdb), the go >> build command needs to be run from within the dir of the module (because of >> the relative paths in the go.mod replace directive I assume). I already >> have a patch for this ( >> https://github.com/sylr/promu/commit/c6e6a2bcdf5d50338b1ee70022c40152a8992c82 >> ). >> >> Regards. >> >> On Fri, 7 Feb 2020 at 18:12, Bjoern Rabenstein <[email protected]> >> wrote: >> >>> I think it became already obvious from the discussion so far: Semantic >>> versioning for the user of the Prometheus server is completely >>> different from semantic versioning for the user of Go packages >>> contained in the Prometheus code base. >>> >>> Conflating both will be bad for both parties. >>> >>> We could have a _separate_ versioning, using vx.y.z tags for the Go >>> module versioning and a new tag naming schema (e.g. release-x.y.z) for >>> user releases. >>> >>> Besides the obvious concerns about this, I also think that semantic >>> versioning for a large number of Go packages together is problematic >>> in any case. Any breaking change in any one package will bump the >>> major version for _all_ packages, leading to new import paths in the >>> Go modules world, which can lead to interoperability problems for >>> indirect users of the packages. (They could find themselves in the >>> situation of assigning a v2/model.Label spit out by one of their >>> direct dependencies to a v3/model.Label required by another of their >>> direct dependencies.) >>> >>> That's why I think Duco's Modularize project has some >>> merits. Alternatively (as I said before), I could see better tooling >>> for maintaining multiple Go modules within the same Git repo as a >>> viable (and less invasive) solution. >>> >>> Therefore, I'd prefer to see how Modularize turns out in practice (or >>> if alternatively somebody comes up with tooling and/or easy-to-follow >>> best practices for multi-module repos) and then reconsider what we can >>> do in prometheus/prometheus. >>> >>> -- >>> Björn Rabenstein >>> [PGP-ID] 0x851C3DA17D748D03 >>> [email] [email protected] >>> >> >> >> -- >> Sylvain Rabot <[email protected]> >> > > > -- > 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/CAP8_5EDBuQWN7GeTLDDnY7xHgP617c69CvWtD_iRVPSMqqHxbg%40mail.gmail.com.
