brew install knative-client

[maximilien]

In what area(s)?

Installation / usability

Classifications:

/kind good-first-issue /kind feature

Describe the feature:

Similar to #323 and #394 would be nice to have a brew formulae for the Kn Knative client

[drnic]

Until knative setups their own homebrew repo + ci job, I've added kn to our homebrew/ci (based on github releases):

$ brew install starkandwayne/kubernetes/knative-client
==> Installing knative-client from starkandwayne/kubernetes
==> Downloading https://github.com/knative/client/releases/download/v0.2.0/kn-darwin-amd64
...

$ kn version
Version:      v0.2.0
Build Date:   2019-07-10 20:57:03
Git Revision: e1614f9
Dependencies:
- serving:    v0.6.0

[rhuss]

nice ;-) We hope to get there soon ...

[kameshsampath]

expecting a official brew package soon

[maximilien]

Hi, @drnic, did you want to contribute this officially? We'd be happy to accept? Let me know and I can help you need too. Thx.

[rhuss]

Yes, we would be happy to include this as well in the installation documentation in https://github.com/knative/docs/blob/master/docs/install/install-kn.md

[rhuss]

@drnic Are you still there ;-) ? Sorry for the long delay. If not, no problem, as someone else could pick this up.

[drnic]

@rhuss I chatted with @maximilien about the steps we need to take, the new repo + permissions I'd need. I can pair with you/someone who has those permissions? I'm in GMT+10/Brisbane AU timezone.

[rhuss]

@drnic could you summarize what repo you would need and which structure ? I'm asking because there is a little bit of process involved in creating a new GitHub repo and adjusting the permission (as we have to ask others because we don't have enough perms for doing so). So there is unfortunately nothing we could do 'live' ;-(

[drnic]

1. [ ] Create https://github.com/knative/homebrew-knative (the name of the repo is important to homebrew, and results in a tap knative/knative)
2. [ ] Copy https://github.com/starkandwayne/homebrew-kubernetes/blob/master/knative-client.rb into its root folder
3. [ ] Setup CI to run a script like https://github.com/starkandwayne/homebrew-kubernetes/blob/master/ci/scripts/update-homebrew.sh to bump the knative-client.rb based on a latest https://github.com/knative/client github release and its assets.

Then brew install knative/knative/knative-client should work.

[rhuss]

@drnic thanks for the writing down the steps required !

@mattmoor Do you think we could establish this new dedicated homebrew repo ? I guess it then can be used as a homebrew tap not only for kn itself but also for kn plugins or for funk (if it should get an own cli).

Also for the CI, I guess we could use Prow for doing the file updates as part of an (auto) release.

[drnic]

Correct; the one repo can house lots of *.rb recipes; and the update-homebrew.sh can bump any specific one in CI

[mattmoor]

brew install knative/knative/knative-client is kind of a mouthful.

I think there's a very strong case for creating a repo to support this, but if its name directly affects the install experience, maybe we should bikeshed that a bit first?

[drnic]

Many ppl break it into two instructions:

brew tap knative/knative brew install

-- Dr Nic Williams Stark & Wayne LLC http://starkandwayne.com +61 437 276 076 twitter @drnic

[rhuss]

Ideally, I would like to have a knative/kn as the preferred choice or knative/knative/kn as a second choice. (so, replacing knative-client by the command name how it is called: kn).

Plugins then could be named like the command, too: kn-build, kn-migrate, ...), or if it's our plugin collection kn-contrib

For the second part, we could also something different than knative to avoid repetition.

Some suggestions for the repo name:

• https://github.com/knative/homebrew-homebrew (--> knative/homebrew)
• https://github.com/knative/homebrew-install (--> knative/install)
• https://github.com/knative/homebrew-client ( --> knative/client, however only when this repo then is reserved for client binaries only).

After writing this :), I like best:

• Using a https://github.com/knative/homebrew-client repository
• Installing a kn.rb declarator

This would lead to this UX:

# Install directly:
$ brew install knative/client/kn
$ brew install knative/client/kn-contrib    # for all plugins
$ brew install knative/client/kn-funk        # for individual plugins

# Install via tap:
$ brew tap knative/client
$ brew install kn
$ brew install kn-contrib
...

[mattmoor]

Many ppl break it into two instructions

I see, this seems much more reasonable, thanks for explaining!

This would lead to this UX

I like this better too.

LMK when I should start pushing for a name in particular, and I'll poke folks.

[rhuss]

@drnic are we good with the proposal in https://github.com/knative/client/issues/400#issuecomment-585592616 ? (i.e. having a repo knative/homebrew-client ? I then would kick off the process to create that repo ...

[drnic]

One common tap name, if there's any pattern at all, would be to name the repo homebrew-tap and then it would be brew install knative/tap.

As research, here is the list of taps I have installed on my laptop. Five are called tap, all others are unique.

$ brew tap | grep -v homebrew/
aquasecurity/trivy
buildpack/tap
cloudfoundry/tap
derailed/k9s
derailed/popeye
gobuffalo/tap
homeport/tap
jenkins-x/jx
julzdiverse/tools
k14s/tap
linode/cli
starkandwayne/cf
starkandwayne/kubernetes

[rhuss]

As I'm not sure whether there will be other homebrew taps below knative/ I still opt for homebrew-client (also because it seems that there is not hard convention.

Also on my machine it looks like:

appsody/appsody
azure/functions
boz/repo
d12frosted/emacs-plus
datawire/blackbird
derailed/k9s
homebrew/cask
homebrew/cask-fonts
homebrew/core
jenkins-x/jx
wagoodman/dive

(not a single tap).

@mattmoor can you please kick the tires to create a knative/homebrew-client repo ? This would be awesome ! The purpose of this repo would be to hold the homebrew formulas for kn and the plugins from client-contrib

[garethr]

Another naming option. Call the repo homebrew-tap. Their isn't exactly a standard here, but there are lots of examples of that. It has the advantage of avoiding some of the repetition issues.

• https://github.com/cloudfoundry/homebrew-tap
• https://github.com/snyk/homebrew-tap
• https://github.com/windmilleng/homebrew-tap

brew install knative/tap/kn

This also has the advantage of folks being able to install one tap, and then grab this and future tools from the same place (rather than installing new taps for every new tool).

[rhuss]

This also has the advantage of folks being able to install one tap, and then grab this and future tools from the same place (rather than installing new taps for every new tool).

I'm open for both knative/homebrew-client or knative/homebrew-tap, both don't suffer from any repetition issue, with homebrew-client focussing on client tooling (as knative's backendpart won't be installed via homebrew for sure).

Let's start a quick poll, and then decide next week when we have released 0.13.0

[rhuss]

Create GitHub repo knative/homebrew-tap which leads to an UX like

brew install knative/tap/kn

brew tap knative/tap
brew install kn
brew install kn-contrib

Upvotes only.

[rhuss]

Create GitHub repo knative/homebrew-client which leads to a UX like

brew install knative/client/kn

brew tap knative/client
brew install kn
brew install kn-contrib

Upvotes only

[cppforlife]

This also has the advantage of folks being able to install one tap, and then grab this and future tools from the same place (rather than installing new taps for every new tool).

this i think leads to a more convenient experience.

[maximilien]

One reason for knative/client/kn is to anticipate other CLIs or homebrew installable components. Thinking specifically of work items from the FaaS WG that is being proposed.

[rhuss]

Sorry for the delay. Let's settle on a knative/homebrew-client repoistory (most votes). I will take that it get's created so that we can start to work on that to include the client.

[rhuss]

The repo hombrew-client has been created and I added an initial formular for 0.13.1 (thanks @drnic !).

Next step is now to setup Prow properly to PR handling and CI. But I think its probably better to make the creation of the PR be part of the release process of kn itself ? (that way we don't need to add a periodic check for a new release, and we can fail the overall release process if the update of this repo fails). wdyt ?

[github-actions[bot]]

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.

[rhuss]

/remove-lifecycle stale /reopen

for the automation step to create the brew release as part of the regular release, let's continue to work on this issue.

[knative-prow-robot]

@rhuss: Reopened this issue.

In response to [this](https://github.com/knative/client/issues/400#issuecomment-736391151): >/remove-lifecycle stale >/reopen > >for the automation step to create the brew release as part of the regular release, let's continue to work on this issue. Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[github-actions[bot]]

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.

[rhuss]

/remove-lifecycle stale /reopen

[maximilien]

@rhuss does this still need to remain open?

[rhuss]

The last missing piece is to add the automatic update of the homebrew repo when a kn release has landed, i.e. creating automatically a PR against homebrew-client which updates the versions. Or, what is probably easier, create the script in homebrew-client that is then called when a release of kn is done and then add the step to call this script to the release documentation.

I think we should start with the latter so we don't have to deal with authentication during the release process.

[github-actions[bot]]

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.