kubebuilder
kubebuilder copied to clipboard
kubernetes-sigs
Package Root
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
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.
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.
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.
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.
HI @DirectXMan12,
Could/Should we do it now as well or add to v3 project?
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
@DirectXMan12 @mengqiy @droot can any of you add this to "scaffolding-v3" milestone, it seems I can't do it
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.
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.
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
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).
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.
@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.
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
Since #2393 was closed as a duplicate I wanted to mention that the ability to choose internal/controller instead of pkg/controller while simoltaneously being able to use pkg/apis is important to my use cases.
Any guidance from maintainers on what changes will be needed (and where) to change the controllers/ and api/ paths?
@camilamacedo86 had a relevant post about this in Kubernetes slack: https://kubernetes.slack.com/archives/CAR30FCJZ/p1662658142047429 posting here for posterity and for my own reminder.
We have been discussing this issue. And we are thinking about accepting this one and changing the default layout into go/v4-alpha. Also, a suggestion made was to scaffold the controllers under the pkg/internal path.
Therefore, we will check it out better and we will raise this again in the next meeting to see if we can agree to a final decision. Please, feel free to attend if you would like to speak about it. More info
Glad to hear it @camilamacedo86. I'm definitely in favor of the change, particularly to put the controllers under internal/ and the APIs under pkg. I wasn't able to make it to today's meeting, but I will come to the next one and see how best I can contribute. :+1:
Regards adding the controllers under internal:
- It is not possible because we need to use the controllers in the main.go
- Also, it might let the impression that would be recommended people import projects in another project when that does not seems like the best approach for the common case scenarios
c/c @shaneutt
It is not possible because we need to use the controllers in the main.go
You can. Internal packages are accessible by packages sharing the path of its parent. Anything under foo.com/bar will be able to access foo.com/bar/internal.
Some people may still prefer to have controllers under pkg though. IMHO the best course of action is to make the paths configurable via the Makefile or PROJECT
Hi @jgillich,
Some people may still prefer to have controllers under pkg though. IMHO the best course of action is to make the paths configurable via the Makefile or PROJECT
That is not achievable via Makefile or PROJECT one and it is out of scope. If you would like to propose available and maintainable solutions to achieve the goal of we are able to have the paths configurable and working for all plugins please feel free to push a design doc so that we can discuss it. WDYT?
Note that users might want to create their own plugins and tools as well. So that they can define other's layouts and use them with kubebuilder CLI (using plugins phase 2 which is implemented already, see: https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/extensible-cli-and-scaffolding-plugins-phase-2.md)
One thing I've never been clear on, is why is this type of option so hard to add to PROJECT so that individual projects can simply choose where they want to put packages?