pkg
pkg copied to clipboard
update-codegen.sh doesn't work outside GOPATH
Expected Behavior
hack/update-codegen.sh should work outside of GOPATH
Actual Behavior
update-codegen either does nothing or uses an incorrect pkg version.
Steps to Reproduce the Problem
- Move repo outside of GOPATH.
- Make a change to the injection generators.
- Run ./hack/update-codegen.sh
- Observe no change to generated code.
I'd love to see this happen too. Unfortunately this has to be tackled in the Kubernetes generators directly. The issue is that those generators always output to {{output-base}}/{{output-package}}/
.
Technically, it does work outside of the GOPATH, but your repo needs to be cloned inside a directory matching -output-package
exactly. For example, if your code is inside ~/my-knative-eventing
and you set -output-base
to ../../
, all generated files will be written to
~/knative.dev/eventing/pkg/client/...
instead of
~/my-knative-eventing/pkg/client/...
because -output-package
is set to knative.dev/eventing
.
/assign Cynocracy
I didn't see this before hitting the corner case myself :) I have a hacky attempt at a fix in knative.dev/networking, if it works I can upstream it into library.
cc @n3wscott @ImJasonH
This is a bug in gengo upstream in Kubernetes.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen
. Mark the issue as
fresh by adding the comment /remove-lifecycle stale
.
/lifecycle frozen
I believe there's a hack @scothis had that created a temporary GOPATH in ./hack/update-codegen.sh
that we could incorporate.
cc @Cynocracy
I first saw this pattern in kpack. It basically involves setting up a fake GOPATH for gengo https://github.com/pivotal/kpack/blob/master/hack/update-codegen.sh#L16-L18
Does this still repro with the new k8s library versions? I was really hoping it did not :(
Fake GOPATH sounds good, we've done similar things internally when we anger the great and powerful Go Mod.