Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"swagger generate cli" generates code that does not compile #2650

Closed
perelman92 opened this issue Oct 19, 2021 · 2 comments · Fixed by #3045
Closed

"swagger generate cli" generates code that does not compile #2650

perelman92 opened this issue Oct 19, 2021 · 2 comments · Fixed by #3045

Comments

@perelman92
Copy link

perelman92 commented Oct 19, 2021

Problem statement

Running swagger generate cli generates code which cannot be compiled.

cli/runner_group_model.go:52:48: cannot use m (type *models.RunnerGroup) as type *models.Runner in argument to retrieveRunnerGroupNameFlags

cli/runner_model.go:27:6: registerRunnerGroupName redeclared in this block
       cli/runner_group_model.go:27:79: previous declaration

cli/runner_model.go:52:53: cannot use m (type *models.Runner) as type *models.RunnerGroup in argument to retrieveRunnerGroupNameFlags

cli/runner_model.go:61:6: retrieveRunnerGroupNameFlags redeclared in this block
        cli/runner_group_model.go:61:115: previous declaration

Swagger specification

swagger: "2.0"
info:
  contact:
    email: support@swagger.com
    name: API Support
    url: https://swagger.com
  title: My API
  version: "1.0"
host: swagger.com:80
basePath: /api/v1
paths:
  /api/runner:
    get:
      consumes:
        - application/json
      operationId: Get Runner
      produces:
        - application/json
      responses:
        "200":
          description: ok
          schema:
            $ref: '#/definitions/Runner'
      tags:
        - Runner
definitions:
  Runner:
    properties:
      group_name:
        type: string
    type: object
  RunnerGroup:
    properties:
      name:
        description: Name should be unique per tenant
        type: string
    type: object

Steps to reproduce

Use the swagger above.

$ swagger generate cli -f swagger.yaml
$ go build cmd/cli/main.go

Environment

swagger version: v0.28.0
go version: go1.17.1
OS: darwin/amd64

@perelman92 perelman92 changed the title go-cli generates code that does not compile "swagger generate cli" generates code that does not compile Oct 19, 2021
@youyuanwu
Copy link
Member

There is a name collision:
Runner - group_name ->RunnerGroupName
RunnerGroup - name -> RunnerGroupName

So generated code has duplicated functions.

Maybe the flag parsing and value reading should be refactored. Or deduplication name should be implemented.
PR welcome.

@youyuanwu youyuanwu added the bug label Oct 19, 2021
@casualjim
Copy link
Member

You can also override the generated name with x-go-name

@fredbi fredbi added the CLI label Dec 23, 2023
fredbi added a commit to fredbi/go-swagger that referenced this issue Jan 4, 2024
* fixes go-swagger#2650

This PR reduces the likelihood of name conflicts, by preventing
generated names to be sensitive to the "same prefix" syndrome
(e.g. Group + "Name" conflicts with "GroupName").

* Also reduced the amount of input-sensitive local var names, when
this is not necessary.
* Tried to lighten a bit the template by handing over naming conventions
to a template function.
* testing: tested manually. It seems that CLI generation is not subject
to any unit tests, so not adding more with this one.

Signed-off-by: Frédéric BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Jan 5, 2024
* fixes go-swagger#2650

This PR reduces the likelihood of name conflicts, by preventing
generated names to be sensitive to the "same prefix" syndrome
(e.g. Group + "Name" conflicts with "GroupName").

* Also reduced the amount of input-sensitive local var names, when
this is not necessary.
* Tried to lighten a bit the template by handing over naming conventions
to a template function.
* testing: tested manually. It seems that CLI generation is not subject
to any unit tests, so not adding more with this one.

Signed-off-by: Frédéric BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Jan 5, 2024
* fixes go-swagger#2969

This PR addresses an issue with goimports not being able
to find another generated package.

When generating files in 2 packages simultaneously (i.e. cli imports models
and files are being generated model per model in both packages),
there are situations when goimports fails to properly resolve the imported
package (i.e. the imported package is not completed and may have errors
while generating).

This fix proceeds in 2 steps: first generate all models, then proceed with
a final generation step ("PostModels") that iterates again over all
models. It is a bit slower, but imports are now safe.

Other additions with this PR:
* updated dependency to golang.org/x/tools
* added go-openapi/strfmt to default imports (was missing and added by
  goimports, but it is best to make it explicit and avoid unnecessary
  import fixes)
* in templates, added standard library imports
* relinted code generated by the CLI templates (check for errors, unused
  args, shadowed variables, prefer // over block comments, blank lines...)
* updated cli.gotmpl to use os.UserConfigDir() and os.HomeDir() rather
  than importing a third party package
* added guard for multiline .Description in calls to PersistentFlags()

Tests:
* added CLI codegen tests for go-swagger#2969, go-swagger#2650 and the latest docker spec
  (used to generate go-swagger/dockerctl)

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Jan 5, 2024
* fixes go-swagger#2969

This PR addresses an issue with goimports not being able
to find another generated package.

When generating files in 2 packages simultaneously (i.e. cli imports models
and files are being generated model per model in both packages),
there are situations when goimports fails to properly resolve the imported
package (i.e. the imported package is not completed and may have errors
while generating).

This fix proceeds in 2 steps: first generate all models, then proceed with
a final generation step ("PostModels") that iterates again over all
models. It is a bit slower, but imports are now safe.

Other additions with this PR:
* updated dependency to golang.org/x/tools
* added go-openapi/strfmt to default imports (was missing and added by
  goimports, but it is best to make it explicit and avoid unnecessary
  import fixes)
* in templates, added standard library imports
* relinted code generated by the CLI templates (check for errors, unused
  args, shadowed variables, prefer // over block comments, blank lines...)
* updated cli.gotmpl to use os.UserConfigDir() and os.HomeDir() rather
  than importing a third party package
* added guard for multiline .Description in calls to PersistentFlags()

Tests:
* added CLI codegen tests for go-swagger#2969, go-swagger#2650 and the latest docker spec
  (used to generate go-swagger/dockerctl)

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Jan 6, 2024
* fixes go-swagger#2650

This PR reduces the likelihood of name conflicts, by preventing
generated names to be sensitive to the "same prefix" syndrome
(e.g. Group + "Name" conflicts with "GroupName").

* Also reduced the amount of input-sensitive local var names, when
this is not necessary.
* Tried to lighten a bit the template by handing over naming conventions
to a template function.
* testing: tested manually. It seems that CLI generation is not subject
to any unit tests, so not adding more with this one.

Signed-off-by: Frédéric BIDON <fredbi@yahoo.com>
fredbi added a commit that referenced this issue Jan 6, 2024
* fixes #2650

This PR reduces the likelihood of name conflicts, by preventing
generated names to be sensitive to the "same prefix" syndrome
(e.g. Group + "Name" conflicts with "GroupName").

* Also reduced the amount of input-sensitive local var names, when
this is not necessary.
* Tried to lighten a bit the template by handing over naming conventions
to a template function.
* testing: tested manually. It seems that CLI generation is not subject
to any unit tests, so not adding more with this one.

Signed-off-by: Frédéric BIDON <fredbi@yahoo.com>
fredbi added a commit to fredbi/go-swagger that referenced this issue Jan 7, 2024
* fixes go-swagger#2969

This PR addresses an issue with goimports not being able
to find another generated package.

When generating files in 2 packages simultaneously (i.e. cli imports models
and files are being generated model per model in both packages),
there are situations when goimports fails to properly resolve the imported
package (i.e. the imported package is not completed and may have errors
while generating).

This fix proceeds in 2 steps: first generate all models, then proceed with
a final generation step ("PostModels") that iterates again over all
models. It is a bit slower, but imports are now safe.

Other additions with this PR:
* updated dependency to golang.org/x/tools
* added go-openapi/strfmt to default imports (was missing and added by
  goimports, but it is best to make it explicit and avoid unnecessary
  import fixes)
* in templates, added standard library imports
* relinted code generated by the CLI templates (check for errors, unused
  args, shadowed variables, prefer // over block comments, blank lines...)
* updated cli.gotmpl to use os.UserConfigDir() and os.HomeDir() rather
  than importing a third party package
* added guard for multiline .Description in calls to PersistentFlags()

Tests:
* added CLI codegen tests for go-swagger#2969, go-swagger#2650 and the latest docker spec
  (used to generate go-swagger/dockerctl)

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>

reindented cli.gotmpl

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
fredbi added a commit that referenced this issue Jan 7, 2024
* fixes #2969

This PR addresses an issue with goimports not being able
to find another generated package.

When generating files in 2 packages simultaneously (i.e. cli imports models
and files are being generated model per model in both packages),
there are situations when goimports fails to properly resolve the imported
package (i.e. the imported package is not completed and may have errors
while generating).

This fix proceeds in 2 steps: first generate all models, then proceed with
a final generation step ("PostModels") that iterates again over all
models. It is a bit slower, but imports are now safe.

Other additions with this PR:
* updated dependency to golang.org/x/tools
* added go-openapi/strfmt to default imports (was missing and added by
  goimports, but it is best to make it explicit and avoid unnecessary
  import fixes)
* in templates, added standard library imports
* relinted code generated by the CLI templates (check for errors, unused
  args, shadowed variables, prefer // over block comments, blank lines...)
* updated cli.gotmpl to use os.UserConfigDir() and os.HomeDir() rather
  than importing a third party package
* added guard for multiline .Description in calls to PersistentFlags()

Tests:
* added CLI codegen tests for #2969, #2650 and the latest docker spec
  (used to generate go-swagger/dockerctl)

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>

reindented cli.gotmpl

Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants