-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Labels
Comments
perelman92
changed the title
go-cli generates code that does not compile
"swagger generate cli" generates code that does not compile
Oct 19, 2021
There is a name collision: So generated code has duplicated functions. Maybe the flag parsing and value reading should be refactored. Or deduplication name should be implemented. |
You can also override the generated name with |
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
Problem statement
Running
swagger generate cli
generates code which cannot be compiled.Swagger specification
Steps to reproduce
Use the swagger above.
Environment
swagger version: v0.28.0
go version: go1.17.1
OS: darwin/amd64
The text was updated successfully, but these errors were encountered: