Add homebrew install instructions? about kubecfg HOT 9 CLOSED

Having an official binary is still useful; Not everyone uses brew. However, it is a very popular package manager, so having it is a nice-to-have (and made showing my devs how to use it a lot easier)

from kubecfg.

Mac user here. Homebrew is popular but not universal, so retaining the binaries is a reasonable thing to do. The usual maintenance procedure with Homebrew is to update the version number and sha256, then file a pull request. There are many formulae which lag the real source repository by a day or three because they're maintained by someone other than the real source maintainer.

Also, I just filed a PR for kubecfg (Homebrew/homebrew-core#25737), since there wasn't an existing one.

from kubecfg.

Homebrew now has kubecfg. The typicall install instructions are:

1. Install Homebrew.
2. brew install kubecfg

from kubecfg.

I'm not a Mac user. Is this preferable to just making the kubecfg darwin executable available from github releases? Should I drop the pre-built executable in favour of the brew formula? Keep both?

from kubecfg.

+1 for darwin executables

EDIT: well it looks like there are darwin builds for older releases but not 0.5.0, any ideas what happened there?

from kubecfg.

EDIT: well it looks like there are darwin builds for older releases but not 0.5.0, any ideas what happened there?

@prydonius travis happened. I've spent days debugging jsonnet_cgo and trying various toolchain combinations, and I still have no idea why "go test" frequently hangs on travis' osx environment in the first(?) test case that invokes jsonnet. I'm assured by mac users that this does not happen for them locally when they run the same commands. It also suddenly started happening on travis without a change in the kubecfg code/setup/vendored-libs - so I'm inclined to blame a travis env issue, but I have also failed to fix it by forcing the build environment to various old versions of tools or base image. I have also stared at the jsonnet_cgo source, and fixed several memory leaks and one potential go-garbage-collection race, all which also failed to unblock the kubecfg osx tests.

So far I manually re-trigger the osx release builds with my fingers crossed and I very occasionally get a successful build. Better solutions are:

• cross-compile from linux->osx. Downside of this is that we can't test the osx binary - so if there actually was a real deadlock issue then we wouldn't know.
• switch to jsonnet-go, on the (untested) assumption that this is a cgo toolchain issue.

from kubecfg.

To the broader homebrew question, I still need advice from a Mac user as to what I'm expected to do here.

I think I need to upload the homebrew recipe to the main homebrew repo, and then continue to manually update the embedded version number with every kubecfg release - is that correct?

from kubecfg.

So far I manually re-trigger the osx release builds with my fingers crossed and I very occasionally get a successful build. Better solutions are:

This perhaps sounds like a different issue, so don't really want to hijack, but now that jsonnet-go is feature complete, it might make sense to move to that. cgo certainly has some limitations (e.g. with static linking) that it would be nice to avoid.

from kubecfg.

I submitted a review for the brew formula. It LGTM but you will need the approval from brew maintainers.

from kubecfg.