GNU implementation's in scripts to support MacOS - #482

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
• Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: JJJJJones
To complete the pull request process, please assign corneliusweig
You can assign the PR to them by writing /assign @corneliusweig in a comment when ready.

The full list of commands accepted by this bot can be found here.

thanks for being thoughtful @JJJJJones how about we do this:

Instead of writing code to support two implementations, we can write a ensure-gnu-tools.sh that we source [...] in scripts where readlink etc are used.
Since number of Krew contributors using macOS is <100, we can just ask them to brew install coreutils findutils grep [...] whatever in an error message if we don't detect ggrep, greadlink etc in PATH.

@ahmetb I realize now the PR is misleadingly named because it does more or less what you said.

Calls to grep/stat/readlink are prevented by hack/verify-code-patterns.sh in favor of two functions, resolvegrep and resolvelink, that ensure for MacOS users the GNU-equivalent programs are checked for and used if found (ggrep and greadlink), otherwise an error is thrown.

If I'm not mistaken there is an option to brew install coreutils which creates symlinks without the g for all binaries. So you can call GNU sed simply as sed instead of gsed.

Maybe this is what we want to recommend? For example

function ensureGNUUtils () {
  if [[ $(uname) == "Darwin" ]]; then
    if ! hash sed 2>/dev/null; then
      echo "Please install the GNU coreutils with `brew install coreutils --with-secret-option`"
      exit 1
    fi
  fi
}

If I'm not mistaken there is an option to brew install coreutils which creates symlinks without the g for all binaries. So you can call GNU sed simply as sed instead of gsed.

I don't see such an option.

✗ brew info coreutils
coreutils: stable 8.31 (bottled), HEAD
GNU File, Shell, and Text utilities
https://www.gnu.org/software/coreutils
Conflicts with:
  aardvark_shell_utils (because both install `realpath` binaries)
  b2sum (because both install `b2sum` binaries)
  ganglia (because both install `gstat` binaries)
  gegl (because both install `gcut` binaries)
  idutils (because both install `gid` and `gid.1`)
  md5sha1sum (because both install `md5sum` and `sha1sum` binaries)
  truncate (because both install `truncate` binaries)
/usr/local/Cellar/coreutils/8.31 (476 files, 8.8MB) *
  Poured from bottle on 2019-12-11 at 15:24:35
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/coreutils.rb
==> Options
--HEAD
	Install HEAD version
==> Caveats
Commands also provided by macOS have been installed with the prefix "g".
If you need to use these commands with their normal names, you
can add a "gnubin" directory to your PATH from your bashrc like:
  PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"
==> Analytics
install: 39,048 (30 days), 118,368 (90 days), 617,935 (365 days)
install-on-request: 35,515 (30 days), 108,162 (90 days), 560,614 (365 days)
build-error: 0 (30 days)

This is the key:

PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"

e.g. https://github.com/ahmetb/dotfiles/blob/78e2c944056223fb55dfd1e5c272b4cb112acdae/.zshrc#L69

I think that'd be a mistake.

Installing coreutils from homebrew and referencing "ggrep" or "greadlink" is idempotent. Modifying the PATH would cause unknown side-effects for developers and maintainers who rely on the MacOS variant of commands (such as me) and requires an extra step of setup for people to work on Krew (which could open up its own problems because of MacOS Catalina's switch from bash to zsh as the default shell).

I've been practically developing on macOS for years in Docker and Kubernetes ecosystem and never hit an issue with this PATH configuration.

It's a reasonable expectation from a developer in Kubernetes ecosystem to have an environment with GNU coreutils.

Anecdata aside, people will forget this and add scripts that directly invoke readlink –and nobody will remember this patch. Assume tomorrow all maintainers have changed, there's nothing to enforce this coding style. That's why I don't think this is the right approach. Hope that makes sense.

Also so far we're only hearing this problem from you despite many people contributing to Krew. I'm trying to paint the picture that this hasn't been a problem and the solution you provide isn't future-proof.

Kubernetes repo contains 344 times sed and 9 times gsed. So it's clear that kubernetes as a project has decided to use GNU coreutils.
As @.ahmetb said, using GNU coreutils has worked fine for him over years on OSX. I'd suggest to try the same and report back if you have trouble.

/close

@corneliusweig: Closed this PR.