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/CADjtP1EgLt--JMvyZrw%3DKyxd%3Da3WJ%3DoaWCsR0Euc5HQwBb7_GA%40mail.gmail.com.
