0

First: I have read through and attempted to apply what I found in related posts, but nothing seems to be working. Related posts would be:

  1. Error "import cycle not allowed" in go-swagger auto generated code

The spec in its most simple form is:

swagger: '2.0'
info:
  version: '0.0.1'
  title: Planting Service
  description: Planting Service is the reference for all planting activities.
  contact: {}
host: www.example.com
basePath: /
securityDefinitions: {}
schemes:
- https
consumes:
- application/json
produces:
- application/json
paths:
  /v1/validations/product-years/{product-year}:
    get:
      description: '**DEPRECATED - Please use GET /v3/validations**'
      summary: (Deprecated) Get planting-specific validations for a given product year
      tags:
      - v1
      operationId: (Deprecated)Getplanting-specificvalidationsforagivenproductyear
      deprecated: true
      produces:
      - application/json
      parameters:
      - name: product-year
        in: path
        required: true
        type: integer
        format: int64
        description: ''
      responses:
        '304':
          description: Not Modified
          headers: {}
        '400':
          description: Bad Request
          headers: {}
        '500':
          description: Server Error
          headers: {}

If you put the spec in a file called swagger.yml in a directory ${GOPATH}/src/planting and then run:

$ cd ${GOPATH}/src/planting
$ go mod init planting
$ swagger generate server -A planting -f swagger.yml
$ go mod tidy
$ cd ./cmd/planting-server && go build

This will result in the following error:

package planting/cmd/planting-server
    imports planting/restapi
    imports planting/restapi/operations
    imports planting/restapi/operations/v1
    imports planting/restapi/operations/v1: import cycle not allowed

Why is go-swagger generating code with cycles in it? My environment is:

System Version: macOS 12.6 (21G115)
Kernel Version: Darwin 21.6.0
go version go1.19.3 darwin/amd64
⚡ swagger version
version: v0.30.3
commit: ecf6f05b6ecc1b1725c8569534f133fa27e9de6b

Running:

golangci-lint run --fix ./...

Unfortunately, does not fix the issue but does show better diagnostic output on where the issues are. All the fixes to cycles entailed removing unused import added by the code generator. Unfortunately, in the real code there are 121 endpoints and each has 3 files that need to be touched up so manually modifying the files is not sustainable. Any suggestions on automated tooling to cleanup after the swagger generate server command?

In my Makefile I have added the following target.

  swagger-touchup:
    # We run find -- goimports twice because of cycles.
    find . -name "*.go" -exec goimports -w {} \; && \
      find . -name "*.go" -exec goimports -w {} \; && \
      find . -name "*.go" -exec gofmt -w {} \; && \
      find . -name "*.go" -exec gofmt -w {} \;
  .PHONY: swagger-touchup

This seems remove most of the cycles which are just unused. Seems like to me those responsible for go-swagger are blindly just adding imports. Unfortunately, server.go and main.go still have unused imports. It would be nice if go-swagger validated their own code and fixed it before the program exited.

Matthew Hoggan
  • 7,402
  • 16
  • 75
  • 140
  • I can manually modify the files afterwards and get it to build, but if I were to run this on all 121 endpoints in the original spec, that seems unnecessary. – Matthew Hoggan Dec 06 '22 at 20:16

0 Answers0