search

knative / func

Knative Functions client API and CLI
Apache License 2.0
275 stars 138 forks source link

fix go install CLI #38

Closed lkingland closed 4 years ago

lkingland commented 4 years ago

go install of the CLI currently fails when run from outside the project directory:

$ go install github.com/boson-project/faas/cmd/faas
src/github.com/boson-project/faas/knative/deployer.go:11:2: cannot find package "knative.dev/client/pkg/kn/core" in any of:
        /usr/lib/go/src/knative.dev/client/pkg/kn/core (from $GOROOT)
        /home/drekar/go/src/knative.dev/client/pkg/kn/core (from $GOPATH)
src/github.com/boson-project/faas/knative/describer.go:9:2: cannot find package "knative.dev/eventing/pkg/apis/eventing/v1alpha1" in any of:
        /usr/lib/go/src/knative.dev/eventing/pkg/apis/eventing/v1alpha1 (from $GOROOT)
        /home/drekar/go/src/knative.dev/eventing/pkg/apis/eventing/v1alpha1 (from $GOPATH)
src/github.com/boson-project/faas/knative/describer.go:10:2: cannot find package "knative.dev/eventing/pkg/client/clientset/versioned/typed/eventing/v1alpha1" in any of:
        /usr/lib/go/src/knative.dev/eventing/pkg/client/clientset/versioned/typed/eventing/v1alpha1 (from $GOROOT)
        /home/drekar/go/src/knative.dev/eventing/pkg/client/clientset/versioned/typed/eventing/v1alpha1 (from $GOPATH

This is likely due to the knative.dev dependency therein not being based on go modules, but may be a different cause. One way to solve this may be to update the knative client dependency to the latest, which I believe are now go modules.

This does not affect standard builds from the repo root (where the go.mod and go.sum files are used

lkingland commented 4 years ago

My expected behavior of the command go install command is currently an active proposal in the Go community. The design document is also available. tl;dr go install does not behave as expected after the introduciton of go modules. It will soon install a package globally into a user's PATH, ignoring any locally-available go module, with go get remaining locally module-aware.

From the issue that spawned the discussion, the workaround is:

# From outside a go module, one can run:
GO111MODULE=on go get foo.com/cmd/bar

This is only a partial solution, because running go get from within a go module adds the dependencies of the referenced module to the local .go.mod.

The purpose of this issue was to fix a problem which precluded adding go install github.com/boson-project/faas/cmd/faas as a valid installation option to our documentation.

Since this above workaround of using go get exhibits potentially unexpected behavior depending on whether or or not it is run from within a go module, we should simply wait for the proposed change to the go install behavior referenced above, and avoid adding this installation method to our documentation.