v1.13.0 introduces lots of transitive dependencies to client library #1142

pgier · 2023-07-10T18:39:33Z

I'm only using oapi-codegen to generate a client library against an openapi spec file. I noticed that when I changed my go.mod to use v1.13.0 instead of v1.12.4, there are lots of transitive dependencies added. There seems to be a lot of stuff added that relate to server code and maybe should not be necessary for a client library.

 go 1.20

-require github.com/deepmap/oapi-codegen v1.12.4
+require github.com/deepmap/oapi-codegen v1.13.0

 require (
        github.com/apapsch/go-jsonmerge/v2 v2.0.0 // indirect
+       github.com/bytedance/sonic v1.9.1 // indirect
+       github.com/chenzhuoyu/base64x v0.0.0-20221115062448-fe3a3abad311 // indirect
+       github.com/gabriel-vasile/mimetype v1.4.2 // indirect
+       github.com/gin-contrib/sse v0.1.0 // indirect
+       github.com/gin-gonic/gin v1.9.1 // indirect
+       github.com/go-playground/locales v0.14.1 // indirect
+       github.com/go-playground/universal-translator v0.18.1 // indirect
+       github.com/go-playground/validator/v10 v10.14.0 // indirect
+       github.com/goccy/go-json v0.10.2 // indirect
        github.com/google/uuid v1.3.0 // indirect
-       github.com/stretchr/testify v1.8.3 // indirect
+       github.com/json-iterator/go v1.1.12 // indirect
+       github.com/klauspost/cpuid/v2 v2.2.4 // indirect
+       github.com/labstack/echo/v4 v4.10.2 // indirect
+       github.com/labstack/gommon v0.4.0 // indirect
+       github.com/leodido/go-urn v1.2.4 // indirect
+       github.com/mattn/go-colorable v0.1.13 // indirect
+       github.com/mattn/go-isatty v0.0.19 // indirect
+       github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect
+       github.com/modern-go/reflect2 v1.0.2 // indirect
+       github.com/pelletier/go-toml/v2 v2.0.8 // indirect
+       github.com/twitchyliquid64/golang-asm v0.15.1 // indirect
+       github.com/ugorji/go/codec v1.2.11 // indirect
+       github.com/valyala/bytebufferpool v1.0.0 // indirect
+       github.com/valyala/fasttemplate v1.2.2 // indirect
+       golang.org/x/arch v0.3.0 // indirect
+       golang.org/x/crypto v0.9.0 // indirect
+       golang.org/x/net v0.10.0 // indirect
+       golang.org/x/sys v0.8.0 // indirect
+       golang.org/x/text v0.9.0 // indirect
+       google.golang.org/protobuf v1.30.0 // indirect
+       gopkg.in/yaml.v3 v3.0.1 // indirect
 )

It appears to be caused by the runtime package as shown by go mod why:

> go mod why github.com/valyala/fasttemplate
# github.com/valyala/fasttemplate
github.com/datastax/pulsar-admin-client-go/src/pulsaradmin
github.com/deepmap/oapi-codegen/pkg/runtime
github.com/labstack/echo/v4
github.com/labstack/gommon/log
github.com/valyala/fasttemplate

I've attached a patch to show the diff of my go.mod and go.sum.
codege_1.12_to_1.13.patch

The text was updated successfully, but these errors were encountered:

pgier · 2023-07-10T18:49:12Z

Digging into this a bit, it appears this is due to this change #1021
which added dependencies on labstack/echo and gin-gonic/gin to the runtime package.

jamietanna · 2023-07-31T10:13:43Z

Thanks for reporting - yeah that looks like it - I agree that we'd probably want to limit the scope of the imports, so we can reduce the tree of dependencies pulled - may be one for a next minor release, or a major release if we wanted to split them up into separate packages with their own go.mods.

I know at least in modern Go (I think since 1.17/1.18) Go will at least not vendor the dependencies it doesn't see in use, but it may still download them in non-vendoring mode 🤔

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. Before we can do this, we need to break some dependencies between packages that don't make sense.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can start with the `examples` project, which definitely shouldn't be pulled by consumers.

jamietanna · 2023-08-18T10:59:10Z

FYI @pgier I'm making progress on this in #1197, I can look at raising a (draft) PR to https://github.com/datastax/pulsar-admin-client-go to pin to the branch I'm working on and show:

whether it's a straight-forward upgrade as a consumer
whether it reduces the impact of our transitive dependencies

Right now the go.mod is very slimmed down, and should be much more palatable!

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can start with the `examples` project, which definitely shouldn't be pulled by consumers.

As part of changes towards solving #1142, we will be migrating to a multi-module Go project, which will not be easily supported by the GitHub Action for golangci-lint, therefore we can replace it with running it via `make`, with the right formatting outputs.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. Before we can do this, we need to break some dependencies between packages that don't make sense.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can start with the `examples` project, which definitely shouldn't be pulled by consumers.

As part of changes towards solving #1142, we will be migrating to a multi-module Go project, which will not be easily supported by the GitHub Action for golangci-lint, therefore we can replace it with running it via `make`, with the right formatting outputs.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. Before we can do this, we need to break some dependencies between packages that don't make sense.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can start with the `examples` project, which definitely shouldn't be pulled by consumers.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which we can start with by removing unnecessary dependencies on `echo` from the `pkg/codegen` project.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. Before we can do this, we can make sure that we have set up our Makefile and `tidy` workflow to be module-aware via steps in [0]. [0]: https://www.jvt.me/posts/2023/08/18/go-multi-module-execute/

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can start with the `examples` project, which definitely shouldn't be pulled by consumers. The fake module version updates across all files due to the way that multi-module Go projects work, but should be a one-time update.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can split each of the middleware packages into their own modules, allowing consumers to pull only the dependences they need.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can migrate `internal/test` to its own module, as it shouldn't be (nor could it be) pulled by consumers. The fake module version updates across all files due to the way that multi-module Go projects work, but should be a one-time update.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. This migrates `pkg/runtime` which unfortunately is still a little heavyweight due to `pkg/runtime/strictmiddleware.go`.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can move `pkg/testutil` to alleviate any other dependencies the root module has on web frameworks, and allow this to be used independently.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. This migrates `pkg/runtime` which unfortunately is still a little heavyweight due to `pkg/runtime/strictmiddleware.go`.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which we can start with by removing unnecessary dependencies on `echo` from the `pkg/codegen` project.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. Before we can do this, we can make sure that we have set up our Makefile and `tidy` workflow to be module-aware via steps in [0]. [0]: https://www.jvt.me/posts/2023/08/18/go-multi-module-execute/

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can start with the `examples` project, which definitely shouldn't be pulled by consumers. The fake module version updates across all files due to the way that multi-module Go projects work, but should be a one-time update.

As part of #1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can migrate `internal/test` to its own module, as it shouldn't be (nor could it be) pulled by consumers. The fake module version updates across all files due to the way that multi-module Go projects work, but should be a one-time update.

As part of #1142 we can start to reduce our transitive dependencies by refactoring the `pkg/runtime` as it exists in deepmap/oapi-codegen. This allows us to introduce a breaking change (tweaking the structure of this package, including moving the `strictmiddleware` concepts) by creating a fresh package. This does require we tweak the way that our imports and generated code works. By moving `runtime` to a separate package, we can allow more frequent updates to the runtime-specific code, without tying it directly to the version of the code generator in use.

ShouheiNishi · 2023-09-08T02:22:12Z

I try to remove dependency of Iris module in "github.com/deepmap/oapi-codegen" and "github.com/oapi-codegen/runtime".

Remove directory "pkg/runtime" and use module "github.com/oapi-codegen/runtime" instead.
Remove directory "pkg/iris-middleware" and use module "github.com/oapi-codegen/iris-middleware" instead.
Split package "github.com/oapi-codegen/runtime/strictmiddleware/iris" to new module "github.com/oapi-codegen/iris-runtime"

Test codes are

But there are breaking changes in these fixes.

jamietanna · 2023-09-11T09:16:20Z

Thanks @ShouheiNishi but we won't be merging those changes for now as the move to using the new oapi-codegen/runtime package should alleviate the issues.

When we do remove the existing packages it'll be for a v2 release at which point we'll have quite a few things to try and clean up, but Marcin and I have been discussing it as a valid option, maybe by the end of the year.

As part of changes towards solving oapi-codegen#1142, we will be migrating to a multi-module Go project, which will not be easily supported by the GitHub Action for golangci-lint, therefore we can replace it with running it via `make`, with the right formatting outputs.

As part of oapi-codegen#1142, we want to reduce the transitive dependencies of oapi-codegen. We can start by breaking some dependencies between packages that don't make sense.

As part of oapi-codegen#1142, we want to reduce the transitive dependencies of oapi-codegen, which we can start with by removing unnecessary dependencies on `echo` from the `pkg/codegen` project.

As part of oapi-codegen#1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. Before we can do this, we can make sure that we have set up our Makefile and `tidy` workflow to be module-aware via steps in [0]. [0]: https://www.jvt.me/posts/2023/08/18/go-multi-module-execute/

As part of oapi-codegen#1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can start with the `examples` project, which definitely shouldn't be pulled by consumers. The fake module version updates across all files due to the way that multi-module Go projects work, but should be a one-time update.

As part of oapi-codegen#1142, we want to reduce the transitive dependencies of oapi-codegen, which requires creating a multi-module Go project. We can migrate `internal/test` to its own module, as it shouldn't be (nor could it be) pulled by consumers. The fake module version updates across all files due to the way that multi-module Go projects work, but should be a one-time update.

As part of oapi-codegen#1142 we can start to reduce our transitive dependencies by refactoring the `pkg/runtime` as it exists in deepmap/oapi-codegen. This allows us to introduce a breaking change (tweaking the structure of this package, including moving the `strictmiddleware` concepts) by creating a fresh package. This does require we tweak the way that our imports and generated code works. By moving `runtime` to a separate package, we can allow more frequent updates to the runtime-specific code, without tying it directly to the version of the code generator in use.

Ahead of #1308 and part of #1142, where we want to remove the `pkg/runtime` module, we need to actually remove the module from any consumers in the project.

As part of #1308 and #1142, ahead of the v2 release, we want to remove any deprecated packages to reduce the dependency tree, and nudge folks to use the separated packages. Closes #1308, #1142.

Ahead of #1308 and part of #1142, where we want to remove the `pkg/runtime` module, we need to actually remove the module from any consumers in the project.

As part of #1308 and #1142, ahead of the v2 release, we want to remove any deprecated packages to reduce the dependency tree, and nudge folks to use the separated packages. Closes #1308, #1142.

Ahead of #1308 and part of #1142, where we want to remove the `pkg/runtime` module, we need to actually remove the module from any consumers in the project.

As part of #1308 and #1142, ahead of the v2 release, we want to remove any deprecated packages to reduce the dependency tree, and nudge folks to use the separated packages. Closes #1308, #1142.

jamietanna added the enhancement New feature or request label Jul 31, 2023

pgier mentioned this issue Aug 7, 2023

upgrade oapi-codegen to v1.13 or higher datastax/pulsar-admin-client-go#2

Closed

jamietanna mentioned this issue Aug 17, 2023

Migrate to multi-module project #1197

Closed

7 tasks

jamietanna mentioned this issue Aug 18, 2023

Use Makefile for linting + increase golangci-lint timeout #1198

Merged

This was referenced Sep 11, 2023

Remove strictmiddleware/iris oapi-codegen/runtime#7

Closed

Remove Iris dependency #1243

Closed

jamietanna mentioned this issue Oct 15, 2023

Remove deprecated packages #1310

Merged

jamietanna added a commit that referenced this issue Oct 15, 2023

Replace test reference to pkg/runtime

69573df

Ahead of #1308 and part of #1142, where we want to remove the `pkg/runtime` module, we need to actually remove the module from any consumers in the project.

jamietanna mentioned this issue Oct 17, 2023

Feat: Add Iris Server Support #1088

Merged

jamietanna added a commit that referenced this issue Oct 31, 2023

Replace test reference to pkg/runtime

d7162c3

Ahead of #1308 and part of #1142, where we want to remove the `pkg/runtime` module, we need to actually remove the module from any consumers in the project.

jamietanna added a commit that referenced this issue Oct 31, 2023

Replace test reference to pkg/runtime

9ee8f5a

Ahead of #1308 and part of #1142, where we want to remove the `pkg/runtime` module, we need to actually remove the module from any consumers in the project.

jamietanna closed this as completed Nov 19, 2023

miquella mentioned this issue Dec 21, 2023

Switch to oapi-codegen/v2 VeeamHub/veeam-vbr-sdk-go#13

Merged

8 tasks

jamietanna mentioned this issue Apr 11, 2024

Add Sprig templates for code generation #1536

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

v1.13.0 introduces lots of transitive dependencies to client library #1142

v1.13.0 introduces lots of transitive dependencies to client library #1142

pgier commented Jul 10, 2023 •

edited

Loading

pgier commented Jul 10, 2023

jamietanna commented Jul 31, 2023

jamietanna commented Aug 18, 2023 •

edited

Loading

ShouheiNishi commented Sep 8, 2023

jamietanna commented Sep 11, 2023

v1.13.0 introduces lots of transitive dependencies to client library #1142

v1.13.0 introduces lots of transitive dependencies to client library #1142

Comments

pgier commented Jul 10, 2023 • edited Loading

pgier commented Jul 10, 2023

jamietanna commented Jul 31, 2023

jamietanna commented Aug 18, 2023 • edited Loading

ShouheiNishi commented Sep 8, 2023

jamietanna commented Sep 11, 2023

pgier commented Jul 10, 2023 •

edited

Loading

jamietanna commented Aug 18, 2023 •

edited

Loading