-
Notifications
You must be signed in to change notification settings - Fork 261
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
Update go.mod to specify the module is go1.14 #866
Conversation
I dunno what's up with the build test - the scripts have deviated from other repos
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, but I wonder whether the motivation is only to use vendoring as we already have vendoring enabeld for go modules since quite some time (e.g.
Line 133 in d8a9692
go build -mod=vendor -ldflags "$(build_flags $(basedir))" -o kn ./cmd/... |
What concrete problem is this PR solving ?
go.mod
Outdated
@@ -6,6 +6,7 @@ require ( | |||
github.com/spf13/pflag v1.0.5 | |||
github.com/spf13/viper v1.6.2 | |||
golang.org/x/crypto v0.0.0-20200302210943-78000ba7a073 | |||
golang.org/x/tools v0.0.0-20200329025819-fd4102a86c65 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why that ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I see. It's for goimports used during build. Does go has the notion of a "developer dependency" (like npm or Maven) ? I'm not big fan to mix in dependencies here which are not part of the application itself.
hack/tools.go
Outdated
@@ -0,0 +1,23 @@ | |||
// +build tools |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this file needed ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, its that you can keep the depedency in go.mod on goimport so that it can be vendored and is not accidentally removed.
It still feels very hackish to me and is a clear smell, that dev dependencies should be managed separately (but it looks like its a go limitation).
I could see two solutions here:
- Don't compile devtools like "goimports" on the fly but use a given binary (like from a container image)
- Use an own kind of vendor by committing dev dependencies in a different vendor dire (vendor_dev) and fiddle with GOPATH before calling
go get goimports
.
I agree that using goimports as it is now is not the correct way, also because the go get
call will update modules.txt
which sometimes leads to a diff to the comitted modules.txt when running in the CI. Up to now fixed the modules.txt manually in such a case, but vendoring seems to be the better solution here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this does not work out or is too involved, than we can of course vendor goimports
.
But we should keep -mod=vendor
for all go commands everywhere to be explicit and not relying on defaults which can change (which seems to happen quite a bit in go-land as just seen when going from go 1.13 to 1.14)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Elaborate a bit on the change as per @rhuss and also update CHANGELOG.md
go1.14 with the presence of a vendor folder will always use Your |
Otherwise te error looks like
|
weird - update licenses seems broken |
Other option if you don't want to pin the tool to a specific |
so I think go code is getting pulled into started a thread here: https://knative.slack.com/archives/CA1DTGZ2N/p1591322638315800 Probably not worth conflating this PR with that concern. |
This should be good now - if you want me to drop vendoring |
@dprotaso If this avoids messing with the client's go.mod this would be then the preferred solution (if this also works locally outside the CI) |
This reverts commit 9616d5e.
rebased since there was a merge conflict |
Thanks ! Let me check later ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, your PR looks small and elegant. But until test-infra is not running on macOs' bash v3 we can reuse the code in the main development script (see comments)
hack/build.sh
Outdated
@@ -16,6 +16,8 @@ | |||
|
|||
set -o pipefail | |||
|
|||
source $(dirname $0)/../scripts/test-infra/library.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, that won't work for macOS. See knative/test-infra#2143
build.sh
is supposed to run on any Unix like OS, also macOS, without any other dependencies. So having Bash 4 dependency here is a no-go, so we can include any test-infra scripts in build.sh.
find $(echo $source_dirs) -name "*.go" -print0 | xargs -0 gofmt -s -w | ||
fi | ||
run_go_tool golang.org/x/tools/cmd/goimports goimports -w $(echo $source_dirs) | ||
find $(echo $source_dirs) -name "*.go" -print0 | xargs -0 gofmt -s -w | ||
set -e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for my former comment about using run_go_tool as I haven't known that the test-infra scripts are not running on the stock bash of macOS.
However, I wonder whether we could inline the run_go_tool
code here, making it running on macOs ?
And even is run_go_tool
happens to run on macOs (by accident), I still wouldn't include library.sh
as long as there is a strong commitment to stick to bash version 3 syntax only.
inlined |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dprotaso, maximilien The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@@ -16,6 +16,9 @@ | |||
|
|||
set -o pipefail | |||
|
|||
[[ ! -v REPO_ROOT_DIR ]] && REPO_ROOT_DIR="$(git rev-parse --show-toplevel)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dprotaso It's that -v which does not work in bash v3
No worries, I'll fix that tomorrow day after tomorrow, sorry.
@maximilien why ? It hasn't been tested on macOS (as requested) and breaks now the build for every macOs user. |
* Update go.mod to specify the module is go1.14 Thus the go commands will default to -mod=vendor See: https://golang.org/doc/go1.14#go-command * install goimports as a tool * drop mod=vendor usage as that's the default with go1.14 * remove comment about using -mod=vendor * Revert "drop mod=vendor usage as that's the default with go1.14" This reverts commit 567004d. * Revert "remove comment about using -mod=vendor" This reverts commit 2a71393. * Revert "install goimports as a tool" This reverts commit 9616d5e. * use go_run_tool to run goimports * inline go_run_tool * include required env var REPO_ROOT_DIR
no worries, the fix was trivial :). Thanks for working on aligning the Knative repos ! |
* Update go.mod to specify the module is go1.14 Thus the go commands will default to -mod=vendor See: https://golang.org/doc/go1.14#go-command * install goimports as a tool * drop mod=vendor usage as that's the default with go1.14 * remove comment about using -mod=vendor * Revert "drop mod=vendor usage as that's the default with go1.14" This reverts commit 567004d. * Revert "remove comment about using -mod=vendor" This reverts commit 2a71393. * Revert "install goimports as a tool" This reverts commit 9616d5e. * use go_run_tool to run goimports * inline go_run_tool * include required env var REPO_ROOT_DIR
- Updates the vendor/modules.txt - Update CHANGELOG - Squashed commits for knative#866 knative#880
- Updates the vendor/modules.txt - Update CHANGELOG - Squashed commits for knative#866 knative#880
- Updates the vendor/modules.txt - Update CHANGELOG - Squashed commits for knative#866 knative#880 knative#883
Thus the go commands will default to -mod=vendor
See: https://golang.org/doc/go1.14#go-command