deps: update oapi-codegen to v2 #4432
Conversation
The oapi-codegen libraries went through a reorganization; the repositories for the oapi-codegen build tool was separated from the runtime libraries. In our go.mod / go_deps.bzl, oapi-codegen build tool no longer shows up. Instead, we explicitly need to require it, in a new macro rules_openapi_dependencies(). Aside; fix `cfg = "exec"` for the oapi-codegen buildtool so that this tool is built for the environment of the builder, not the target platform.
There was a problem hiding this comment.
Reviewable status: 0 of 36 files reviewed, 1 unresolved discussion (waiting on @matzf)
a discussion (no related file):
Have you considered adding oapi-codgen to tools.go?
I think it would be a nicer solution than manually maintaining the required go dependencies.
There was a problem hiding this comment.
Reviewable status: 0 of 36 files reviewed, 1 unresolved discussion (waiting on @oncilla)
a discussion (no related file):
Previously, oncilla (Dominik Roos) wrote…
Have you considered adding oapi-codgen to tools.go?
I think it would be a nicer solution than manually maintaining the required go dependencies.
Interesting, no I haven't considered this, I'll give it a shot.
Generally I find it awkward that the go.mod file is polluted with build tools and all kinds of random garbage, so I wouldn't agree that is a nicer solution, but it certainly is the easiest.
I was happy to remove things from go.mod (I was only disappointed that it wasn't more). What I would have preferred is to keep the dependencies of the oapi-codegen tool entirely separate from the other go_deps.bzl -- it's strange to me that rules_go seems to insist that everything in the workspace must be compiled with the same dependency versions.
Instead of manually managing the oapi-codegen dependencies, add a dummy .go file that forces the dependencies into go.mod.
There was a problem hiding this comment.
Reviewable status: 0 of 38 files reviewed, 1 unresolved discussion (waiting on @oncilla)
a discussion (no related file):
Previously, matzf (Matthias Frei) wrote…
Interesting, no I haven't considered this, I'll give it a shot.
Generally I find it awkward that the
go.modfile is polluted with build tools and all kinds of random garbage, so I wouldn't agree that is a nicer solution, but it certainly is the easiest.I was happy to remove things from
go.mod(I was only disappointed that it wasn't more). What I would have preferred is to keep the dependencies of the oapi-codegen tool entirely separate from the othergo_deps.bzl-- it's strange to me that rules_go seems to insist that everything in the workspace must be compiled with the same dependency versions.
Done.
There was a problem hiding this comment.
Reviewed 30 of 36 files at r1, 14 of 14 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @matzf)
a discussion (no related file):
Previously, matzf (Matthias Frei) wrote…
Done.
I think with dependency graph pruning, there is less of an issue with having a lot of dependencies in go.mod file.
alternative is to have a multi-module repo. But that has another can of worms that we don't want to worry about yet IMO.
There was a problem hiding this comment.
Reviewable status:
complete! all files reviewed, all discussions resolved (waiting on @matzf)
The oapi-codegen libraries went through a reorganization; the repositories for the oapi-codegen build tool was separated from the runtime libraries. In our normal code dependencies, the oapi-codegen build tool no longer shows up. Import it in a dummy .go file as an easy way to ensure that we have all the appropriate dependencies (via the `go.mod`/`go_deps.bzl`) . This leaves some clutter in the `go.mod` file which is not aesthetically pleasing, but is not a real issue due to dependency graph pruning. The alternative solution would have been to manage the dependencies of the `rules_openapi` bazel rules explicitly in a `rules_openapi_dependencies` macro. This turns out to be rather cumbersome, and can lead to unexpected or even invalid dependency version combinations, because `rules_go` does not have a way to separate the dependencies of the build tools from the dependencies of the code. Aside; fix `cfg = "exec"` for the oapi-codegen buildtool so that this tool is built for the environment of the builder, not the target platform.
The oapi-codegen libraries went through a reorganization; the repositories for the oapi-codegen build tool was separated from the runtime libraries.
In our normal code dependencies, the oapi-codegen build tool no longer shows up. Import it in a dummy .go file as an easy way to ensure that we have all the appropriate dependencies (via the
go.mod/go_deps.bzl) . This leaves some clutter in thego.modfile which is not aesthetically pleasing, but is not a real issue due to dependency graph pruning.The alternative solution would have been to manage the dependencies of the
rules_openapibazel rules explicitly in arules_openapi_dependenciesmacro. This turns out to be rather cumbersome, and can lead to unexpected or even invalid dependency version combinations, becauserules_godoes not have a way to separate the dependencies of the build tools from the dependencies of the code.Aside; fix
cfg = "exec"for the oapi-codegen buildtool so that this tool is built for the environment of the builder, not the target platform.This change is