You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the server code which gets generated contains a line with hard-coded //go:generate part. Specifically it assumes that swagger is always pre-installed somewhere and available in the $PATH.
Managing tools like go-swagger as an external dependency however brings a number of challenges, not least one related to differences between platforms (OS/arch). This is why Go has an established common pattern for maintaining tools like these as regular dependencies via tools.go, see https://go.dev/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module for more. One possible consequence of this approach is that the tool is launched via go run rather than directly.
Meaning, that instead of
//go:generate swagger generate ...
one would have
//go:generate go run github.com/go-swagger/go-swagger/cmd/swagger generate ...
Currently, the server code only generates the top version. While I understand that the particular file involved is safe to edit I still think it would be helpful if it could be generated with best practices in the beginning, so it does not have to be edited.
This could probably be achieved in two ways - either it may become another CLI flag of some kind, or it could just be detected automatically from os.Args.
Problem statement
Currently the server code which gets generated contains a line with hard-coded
//go:generate
part. Specifically it assumes thatswagger
is always pre-installed somewhere and available in the$PATH
.Managing tools like
go-swagger
as an external dependency however brings a number of challenges, not least one related to differences between platforms (OS/arch). This is why Go has an established common pattern for maintaining tools like these as regular dependencies viatools.go
, see https://go.dev/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module for more. One possible consequence of this approach is that the tool is launched viago run
rather than directly.Meaning, that instead of
//go:generate swagger generate ...
one would have
//go:generate go run github.com/go-swagger/go-swagger/cmd/swagger generate ...
Currently, the server code only generates the top version. While I understand that the particular file involved is safe to edit I still think it would be helpful if it could be generated with best practices in the beginning, so it does not have to be edited.
This could probably be achieved in two ways - either it may become another CLI flag of some kind, or it could just be detected automatically from
os.Args
.Swagger specification
Steps to reproduce
Generate server code
Open
./restapi/configure_example.go
Environment
swagger version: v0.30.5
go version: go1.21.5
OS: darwin/arm64
The text was updated successfully, but these errors were encountered: