Skip to content

codegen: Conflict with provided Kinds #666

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

Closed
bcotton opened this issue Feb 26, 2025 · 0 comments · Fixed by #712
Closed

codegen: Conflict with provided Kinds #666

bcotton opened this issue Feb 26, 2025 · 0 comments · Fixed by #712
Assignees

Comments

@bcotton
Copy link
Contributor

bcotton commented Feb 26, 2025

I happen to have several Kinds that are generically named, e.g. component, resource, group, system, domain, user.

In a few instances, in generated code, these terms conflict with the generated terms. Here are two such cases:

  1. with a kind of resource the package from github.com/grafana/grafana-app-sdk/resource would conflict, and I would have to rename the generated import to sdk_resource
  2. with a kind of group the generated constants.go generates a Group const that clashes with the Kind.

#1 is not bad as it manifests in operator code, which is typically on generated once.
#2 is in code that is re-generated often

pkg/generated/resource/group/v1alpha1/constants.go

const (
	// Group is the API group used by all kinds in this package
	Group = "servicemodel.ext.grafana.com"
	// Version is the API version used by all kinds in this package
	Version = "v1alpha1"
)

Perhaps ApiGroup or somesuch

@IfSentient IfSentient self-assigned this Mar 18, 2025
IfSentient added a commit that referenced this issue Apr 1, 2025
Rename generated 'Group' and 'Version' constants to 'APIGroup' and
'APIVersion' to avoid naming conflicts with kinds. Use
machinename+version for package alias in generated watcher code to avoid
similar conflicts.

Resolves #666
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants