Expose kubectl and helm

[mattfarina]

Through the preference UI, provide checkboxes to symlink kubectl and helm to /usr/local/bin on mac.

The goal of this is to provide the users with access to these tools. Eventually we will have other applications to expose here.

[jandubois]

Please make sure not to overwrite an installed tool with a symlink; the user might already manage these commandline tools using a package manager like homebrew or MacPorts. So just toggling a checkbox should not overwrite a file without at least a confirmation dialog.

[mattfarina]

I would go do far as to say that if a user as something already installed the option should be greyed out and there should be a note saying the tool is already installed and managed elsewhere.

[jandubois]

Alternate implementation idea: instead of symlinking the executables to /usr/local/bin create a file in /etc/paths.d that includes the path to the ./resources/darwin/bin directory.

These paths will be added automatically to the PATH via /etc/profile:

if [ -x /usr/libexec/path_helper ]; then
	eval `/usr/libexec/path_helper -s`
fi

For example VMware Fusion is using this approach:

$ cat /etc/paths.d/com.vmware.fusion.public
/Applications/VMware Fusion.app/Contents/Public

$ ls "$(cat /etc/paths.d/com.vmware.fusion.public)"
containerd               include                  open_source_licenses.txt vctl                     vmrun
containerd-shim-crx-v2   libvixAllProducts.dylib  swagger.zip              vmrest

If people have their own versions in /usr/local/bin, then they will shadow the versions from the default PATH automatically.

Thoughts?

[mattfarina]

@jandubois I've never used this method before. Three thoughts come to mind...

1. Writing to /etc will always require requesting user/pass. Putting in /usr/local/bin won't require user/pass for system if homebrew is installed. I just noticed this.
2. I wonder why VS Code does things the way it does. It does the /usr/local/bin location.
3. If we install something like kubectl using /etc/paths.d and they install an older version via another method... will the version mismatch cause confusion? Our version being shadowed but them opting in to use it might cause some questions. Should the version in use be explicit?

[mattfarina]

@ericpromislow The Rancher Dashboard has a checkbox component. It uses jQuery so I'd want to alter it for our use. But, the setup and styles would help us to keep the design in line with the Rancher Dashboard UI.

[jandubois]

@mattfarina I agree that there are pros and cons to each method; I have no clear opinion on which one is preferable.

1. I think installation of the hyperkit machine driver requires root access anyways (if not already installed by Docker), but I might be wrong.

2. Yes, PATH shadowing can create confusion; not sure how to avoid it though. If Docker is already installed, there may be symlinks to the Docker version of the tools in /usr/local/bin; how would we deal with that?

So we'll get additional complexity when updating RD and there are still symlinks to the previous install in place. We need special logic to allow overriding symlinks to our own previous install, but not symlinks to others? I guess you can always allow replacing of dangling symlinks, but either way, it can get confusing.

Ideally the GUI will have logic to analyze the current setup and then provide assistance about conflicting configuration etc, but that should not be part of the initial implementation. A "Config Wizard" :)

[ericpromislow]

I'll start off bringing over the dashboard component and vueifying it. And I'll assume we'll implement the original symlinks story and then modify as we learn more.

[ericpromislow]

So the linking only happens if there is no instance of the executable, linked or not, in /usr/local/bin

Unlinking is done only if the executable is a link pointing at the app's own executable. In other words, we created that link.

[mattfarina]

Closing as this has been implemented.