search

habitat-sh / habitat-operator

A Kubernetes operator for Habitat services
Apache License 2.0
61 stars 17 forks source link

`make codegen` assumes dependency of `k8s.io/code-generator` #330

Closed surajssd closed 6 years ago

surajssd commented 6 years ago

This makefile target assumes that there is code available in $GOPATH/src/k8s.io/code-generator, this needs fix.

$ make codegen
CODEGEN_PKG=../../../k8s.io/code-generator hack/update-codegen.sh
hack/update-codegen.sh: line 41: ../../../k8s.io/code-generator/generate-groups.sh: No such file or directory                                                                                                     
make: *** [Makefile:65: codegen] Error 127
krnowak commented 6 years ago

What needs to be done for make codegen is written down here: https://github.com/habitat-sh/habitat-operator/blob/master/hack/update-codegen.sh#L20-L28

surajssd commented 6 years ago

@krnowak this could possibly pollute my $GOPATH and if I am working on some code in there it could fail.

krnowak commented 6 years ago

I don't understand the argument of polluting $GOPATH. $GOPATH is the place for the go packages and the code generator is one of those. But maybe it is about some of your workflows related to $GOPATH I have no clue about.

About working on the code generator at the same time - I think that working on the generator and the habitat operator at the same time is such a rare occurrence that I can handwave it with saying "stash or commit your changes to some branch beforehand". The fact that we use the generator only sporadically makes me handwave it even more. ;)

But yeah, probably other solution would be vendoring it, but I don't know if you can vendor arbitrary package (I have been lucky enough to not being forced at the go vendoring again since godep was a thing), since usually you vendor what you import and code generator is not a such thing. Also, I don't know what kind of annoyances would it involve when we tried to vendor it and then update it; vendoring usually is annoying. :) On top of that, the generator is used only sporadically, so not sure if vendoring is worth the fuss.

What do you think? Maybe you have some other ideas.

surajssd commented 6 years ago

@krnowak so I was taking a look at the operator-sdk and taking some inspiration from there, what I noticed is that we can vendor the code-generator repository like this https://github.com/surajssd/yoyo-operator-/blob/4bfea412d2090e10ab05f040776f57577d7d8435/Gopkg.toml#L2-L18

And then use like we do the way it is done here https://github.com/surajssd/yoyo-operator-/blob/4bfea412d2090e10ab05f040776f57577d7d8435/tmp/codegen/update-generated.sh#L7

surajssd commented 6 years ago

If you ack on this, I can create a PR with those changes, this will also help us remove the extra step we do in the circle CI https://github.com/habitat-sh/habitat-operator/blob/85e74446825215363b1b353a65d05331c2b95f7f/.circleci/config.yml#L23-L35