Kubebuilder: Package Root

[moserke]

Add the ability to set the Go package root. Currently api and controller is created in the root of the project. It would be nice to be able to specify putting these packages in pkg to maintain good Go hygiene.

/kind feature

[DirectXMan12]

I suspect this'll have to wait until after we clean up the scaffolding code -- it'd add to the mess to implement this right now.

That being said, while I'm not against supporting this, I'd like to note that "pkg" isn't necessarily the "one true way" to do Go projects. Moving away from "pkg" was somewhat intentional -- while it was clear to Kubernetes contributors, the "pkg" and "cmd" bifrucation wasn't always clear to external users, who looked for a main.go file.

[moserke]

Agreed that it's not the only way, but personally I feel like the pkg & cmd separation is becoming the idiomatic way of laying out a project. Coming from more than just k8s repos it did feel a little out of the normal not to have that structure.

That said though, I completely understand how serving everyone is difficult and there is never going to be the perfect solution. Appreciate the willingness to look into supporting this.

Once the code is ready for more changes like this, I'm also happy to help implement this! Would enjoy getting more plugged in to the community.

[DirectXMan12]

/priority important-longterm

[vincepri]

/cc

[hudymi]

Can two locations be considered? Root for api and separate root for controllers and webhooks. In our projects, we like to have core implementation that shouldn't be imported by any other project in the internal package and things like api in pkg. So for us, it would be convenient to have the ability to configure it.

[DirectXMan12]

at a certain point, too many configuration settings makes this a bit weird. KB itself is supposed to be a recommendation for how to use things -- it's one of the reasons we try hard to keep generic stuff in controller-tools and controller-runtime, so that more complex and/or project-specific layouts can be used. We'll have to weigh the costs of "how do we prevent this from becoming a free-for-all" with each of the options.

[camilamacedo86]

HI @DirectXMan12,

Could/Should we do it now as well or add to v3 project?

[DirectXMan12]

prob v3 (or in a plugin) if we decide to do it at all.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[Adirio]

/lifecycle frozen
/milestone scaffolding-v3

[Adirio]

@DirectXMan12 @mengqiy @droot can any of you add this to "scaffolding-v3" milestone, it seems I can't do it

[DirectXMan12]

done

[DirectXMan12]

you need to be a maintainer to use /milestone at the moment, which is a weird designation that we carried over from Kubernetes but didn't actually want to use. Someone needs to fix the permissions so that reviewers & approvers can /milestone too, or something. The current permission set is weird.

[DirectXMan12]

This seems like a decent candidate to use as a test for plugins phase 2 -- it's mostly a matter of preference, and should be something that's easily doable under our general deisgn currently.

[camilamacedo86]

Hi @DirectXMan12,

I have been thinking about it. Personally, I do not believe that it could be addressed in the plugins phase 2 because who is asking it are the end-users who are looking for to use the Kubebuilder tool to scaffold the projects in this layout. Then, the plugins are useful for who is looking for this project as a lib to create their tools extending it such as SDK.

Also, I think that allows changing the path to scaffold the files will increase the complexity of the plugin phase 2 and would make hard address stories such as I'd like to build my project with kubebuilder but use the SDK features to integrate it with OLM.

Also, regards the argumentation over it be a matter of preference than shows that many folks have from the community has this preference since this change would make the scaffolded project follow up common practices. See for example; https://github.com/golang-standards/project-layout#pkg

[DirectXMan12]

Personally, I do not believe that it could be addressed in the plugins phase 2 because who is asking it are the end-users who are looking for to use the Kubebuilder tool to scaffold the projects in this layout

Plugins phase 2 will most likely involve out-of-tree plugins. That means that we could have an example plugin for "scaffold under pkg".

Also, I think that allows changing the path to scaffold the files will increase the complexity of the plugin phase 2 and would make hard address stories such as I'd like to build my project with kubebuilder but use the SDK features to integrate it with OLM.

I'm not following, can you clarify here? Under what we've brainstormed for phase 2, this should be fairly trivial -- receive the world object, rewrite all .go path keys to have the extra pkg (except /main.go, which goes, under cmd), and then fix up the imports in those go files (parse with the go/xyz packages, edit the imports, then re-serialize with the same packages).

[camilamacedo86]

Hi @DirectXMan12,

So, your idea is that the user could choose, I mean have an option in the KB commands to choose the plugin option to do scaffold as A or B or C. Am I right? Then, I agree that if other tools extending it also would still able to work with the N available options.

[DirectXMan12]

@camilamacedo86 while I'm not exactly certain what the final shape of plugins part 2 would be, I'd expect you'd end up having the "move everything to pkg and cmd" plugin be the last one, so other things scaffold as normal and then that plugin move things around. That's how people would get to chose, and other scaffolding and plugins would still be able to work with both options.

[camilamacedo86]

Adding the label triage/blocked since it is the same status of the #1724 discussed in the bug triage meeting.
We need to wait for the plugin phase 2: https://github.com/kubernetes-sigs/kubebuilder/issues/1378