Skip to content
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

Merged
merged 10 commits into from
Jun 8, 2020

Conversation

dprotaso
Copy link
Member

Thus the go commands will default to -mod=vendor

See: https://golang.org/doc/go1.14#go-command

@googlebot googlebot added the cla: yes Indicates the PR's author has signed the CLA. label May 29, 2020
@knative-prow-robot knative-prow-robot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label May 29, 2020
@knative-prow-robot knative-prow-robot added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. and removed size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. labels May 29, 2020
@dprotaso
Copy link
Member Author

I dunno what's up with the build test - the scripts have deviated from other repos

-----------------------------------------
---- Checking for forbidden licenses ----
-----------------------------------------
---- Fri May 29 15:18:50 PDT 2020
-----------------------------------------
Step failed: default_build_test_runner
============================
==== BUILD TESTS FAILED ====
============================
==== Fri May 29 15:19:20 PDT 2020
============================
Step failed: run_build_tests

@knative-prow-robot knative-prow-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels May 29, 2020
Copy link
Contributor

@rhuss rhuss left a 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.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why that ?

Copy link
Contributor

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
Copy link
Contributor

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 ?

Copy link
Contributor

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.

Copy link
Contributor

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)

Copy link
Contributor

@maximilien maximilien left a 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

@knative-prow-robot knative-prow-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 3, 2020
@dprotaso
Copy link
Member Author

dprotaso commented Jun 5, 2020

go1.14 with the presence of a vendor folder will always use -mod=vendor for various go commands.

Your verify-codegen.sh tries to install the package but it's missing from vendor. To vendor it we need to reference the package being installed - the convention used is to have a tools.go file.

@dprotaso
Copy link
Member Author

dprotaso commented Jun 5, 2020

Otherwise te error looks like

# ./hack/verify-codegen.sh
can't load package: package golang.org/x/tools/cmd/goimports: cannot find package "." in:
	/go/client/vendor/golang.org/x/tools/cmd/goimports

@knative-prow-robot knative-prow-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 5, 2020
@dprotaso
Copy link
Member Author

dprotaso commented Jun 5, 2020

weird - update licenses seems broken

@dprotaso
Copy link
Member Author

dprotaso commented Jun 5, 2020

Other option if you don't want to pin the tool to a specific sha is to use test-infra's run_go_tool

@dprotaso
Copy link
Member Author

dprotaso commented Jun 5, 2020

so I think go code is getting pulled into third_party if it's unable to determine the license for the file.

started a thread here: https://knative.slack.com/archives/CA1DTGZ2N/p1591322638315800

Probably not worth conflating this PR with that concern.

@dprotaso
Copy link
Member Author

dprotaso commented Jun 5, 2020

This should be good now - if you want me to drop vendoring goimports let me know and I can switch to the go_run_tool option

test/presubmit-tests.sh Outdated Show resolved Hide resolved
hack/build.sh Outdated Show resolved Hide resolved
@rhuss
Copy link
Contributor

rhuss commented Jun 5, 2020

This should be good now - if you want me to drop vendoring goimports let me know and I can switch to the go_run_tool option

@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)

@knative-prow-robot knative-prow-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Jun 5, 2020
@dprotaso
Copy link
Member Author

dprotaso commented Jun 8, 2020

rebased since there was a merge conflict

@rhuss
Copy link
Contributor

rhuss commented Jun 8, 2020

Thanks ! Let me check later ...

Copy link
Contributor

@rhuss rhuss left a 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
Copy link
Contributor

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
Copy link
Contributor

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.

@dprotaso
Copy link
Member Author

dprotaso commented Jun 8, 2020

inlined

Copy link
Contributor

@maximilien maximilien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 8, 2020
@knative-prow-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@knative-prow-robot knative-prow-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 8, 2020
@knative-prow-robot knative-prow-robot merged commit a7ea77d into knative:master Jun 8, 2020
@dprotaso dprotaso deleted the patch-1 branch June 8, 2020 20:42
@@ -16,6 +16,9 @@

set -o pipefail

[[ ! -v REPO_ROOT_DIR ]] && REPO_ROOT_DIR="$(git rev-parse --show-toplevel)"
Copy link
Contributor

@rhuss rhuss Jun 8, 2020

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.

@rhuss
Copy link
Contributor

rhuss commented Jun 9, 2020

/lgtm

@maximilien why ? It hasn't been tested on macOS (as requested) and breaks now the build for every macOs user.

@rhuss
Copy link
Contributor

rhuss commented Jun 9, 2020

inlined

@dprotaso I meant "inline the logic of that function", not to inline it literally, as this is not better than sourcing library.sh (as seen in #882 )

rhuss pushed a commit to rhuss/knative-client that referenced this pull request Jun 10, 2020
* 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
@dprotaso
Copy link
Member Author

inlined

@dprotaso I meant "inline the logic of that function", not to inline it literally, as this is not better than sourcing library.sh (as seen in #882 )

I see my mistake - sorry for the trouble

@rhuss
Copy link
Contributor

rhuss commented Jun 12, 2020

I see my mistake - sorry for the trouble

no worries, the fix was trivial :). Thanks for working on aligning the Knative repos !

navidshaikh pushed a commit to navidshaikh/client that referenced this pull request Jun 16, 2020
* 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
navidshaikh pushed a commit to navidshaikh/client that referenced this pull request Jun 16, 2020
 - Updates the vendor/modules.txt
 - Update CHANGELOG
 - Squashed commits for
   knative#866
   knative#880
navidshaikh added a commit to navidshaikh/client that referenced this pull request Jun 16, 2020
 - Updates the vendor/modules.txt
 - Update CHANGELOG
 - Squashed commits for
   knative#866
   knative#880
navidshaikh added a commit to navidshaikh/client that referenced this pull request Jun 16, 2020
 - Updates the vendor/modules.txt
 - Update CHANGELOG
 - Squashed commits for
   knative#866
   knative#880
   knative#883
knative-prow-robot pushed a commit that referenced this pull request Jun 16, 2020
- Updates the vendor/modules.txt
 - Update CHANGELOG
 - Squashed commits for
   #866
   #880
   #883
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cla: yes Indicates the PR's author has signed the CLA. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants