-
Notifications
You must be signed in to change notification settings - Fork 345
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
Migrate to Go modules #675
Conversation
Great job! |
I assumed Camel K wasn't consumed. It seems possible to have non-module consumers. It may be necessary to keep the Dep manifests around. That being said, in the specific case of the Camel K API package being imported into Knative, the transitive dependencies contraints may be better left defined by Knative anyway. So it may be just fine removing the Dep manifests altogether. |
Or, a better approach would be to make sure we don't use external dependencies in the API section, that is a good practice I've seen in other projects. |
Yes, that'd be even better. It may not be practical for the k8s APIs / primitives that we extend, though restricting to them would probably be acceptable. |
@nicolaferraro @astefanutti is there anything here that still need to be done ? |
I'm not sure about vendoring. Do we want to remove the vendor dir? It seems practical to me to have it synchronized there... |
I would suggest we keep the Dep manifests around for a while. It seems this is the strategy some components have adopted, as the ecosystem is transitioning to Go modules. Such an example is https://github.com/kubernetes-sigs/controller-runtime. |
I've just repushed with the |
What do you think about pushing "vendor" as we've done so far? @astefanutti , @lburgazzoli |
My understanding / opinion is that This is also the pattern I'm seeing in the k8s ecosystem as modules are being rolled-out. |
Sounds great so! |
No description provided.