Release a go mod version (with no replace)

[hunshcn]

What would you like to be added?

The go.mod content of k8s.io/kubernetes contains the replace directive, which makes it cumbersome to import it (requires replace k8s.io/*).

When we release a new version, is it possible to release a version for go mod k/k, e.g. v1.29.7-mod.

Since it's already been released, it would be possible to have k8s.io/* use the corresponding version instead of replace, like in v1.29.7, use

require k8s.io/api v0.29.7

I tried it and it works fine hunshcn@72b15e5
(current usage is replace k8s.io/kubernetes => github.com/hunshcn/kubernetes v1.29.7-mod)

I know that k/api's v0.29.7 was created according to k/k's v1.29.7, so I propose to create a new v1.29.7-mod to use v0.29.7.

This seems like something that should be done by test-infra, but since it's related to the main repository, it's posted here

Why is this needed?

This can be helpful in certain scenarios where you need to import k/k, such as scheduling-framework.

OR make scheduling-framework out of k/k ?

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[hunshcn]

/sig release
/sig architecture

[saschagrunert]

Hey @hunshcn, I'd say k/k should not be imported directly, that's what the staging repos (like k8s.io/api) are for.

[hunshcn]

Hey @hunshcn, I'd say k/k should not be imported directly, that's what the staging repos (like k8s.io/api) are for.

But building Custom Scheduler Plugins need import k/k.

[hunshcn]

k/k's import problem with scheduler has been mentioned 3 years age #107263.

The current common practice is to do replace, such as sigs.k8s.io/kube-scheduler-simulator/simulator, which doesn't make much sense.

If k/k doesn't want to be imported, we may need to move the scheduler to k8s.io/scheduler?

If the scheduler remains in k/k, then this issue makes sense.

[k8s-ci-robot]

@hunshcn: The label(s) sig/scheduler cannot be applied, because the repository doesn't have them.

Details

In response to this:

may be related

/sig scheduler

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[hunshcn]

may be related

/sig scheduling

[BenTheElder]

re: replace statements, see the dependency scripts under hack/, these are used intentionally to pin deps, we also actually build from vendor, and we have go.work now.

If k/k doesn't want to be imported, [..]

It has been the general stance that this is not considered supported (though even some other subprojects do it, we're just not taking features/bugs related to it), and I'm pretty sure I raised this on the discussion for scheduler plugins.

[...] we may need to move the scheduler to k8s.io/scheduler?

That's not super realistic and doesn't really change that anyone building a plugin needs to match the go packages and go version exactly.

I personally don't think go plugins are a great approach and it would be better to revisit that part, or else accept that scheduler extensions will have to deal with this.

I've also previously raised this but ... Go's official docs for plugins mostly consist of warnings about drawbacks to using them: https://pkg.go.dev/plugin#hdr-Warnings

Runtime crashes are likely to occur unless all parts of the program (the application and all its plugins) are compiled using exactly the same version of the toolchain, the same build tags, and the same values of certain flags and environment variables.

This goes way past how we manage go.mod