The future of symlinks in krews installation procedure

[corneliusweig]

Krew tries hard to not break an existing plugin installation, if something during install goes awry. To that end, krew uses symlinks to create a pointer from $KREW_HOME/bin/kubectl-<plugin_name> into the fully prepared plugin folder $KREW_HOME/store/<plugin_name>/v1.0/my-exe. This can happen very late in the installation procedure and is pretty much atomic. The only thing that could fail thereafter is removing the previous plugin version folder, which would take up space but is harmless otherwise.

This has worked pretty well for all UNIX like systems which support symlinks.

---

However, it pretty much failed for Windows, because the installation user needs administrator privileges to create symlinks on Windows. Thus we need to recommend installation with admin privileges, which is pretty sad.

As a consequence, I think that far less Windows users want or can adopt krew and our reach stays below its potential (think about users on corp machines). Therefore, let's discuss if we can come up with an installation procedure that does not require symlinks. I think we need to balance the potential impact against the risk of less reliable installation on other OSes.

[ahmetb]

/lifecycle frozen
/area platform/windows

This needs input from Windows users.

We fail krew's installation on Windows early on with a message indicating elevated access. From my experience, most of the time, you want to be on a privileged shell (cmd or PS) to get things done, so it's expected.

If it's been blocking users (we don't know that) we should probably think of a solution. Otherwise, having two different installation methods is less than ideal for maintenance reasons.

[webmutation]

Hi, I am on a corporate laptop and we face exactly this restriction, for this reason we cant rollout krew to 200+ developers within our organization.

Currently this is the only problem we face, we are not able to create the symlinks... as a workaround we copy the files and rename them... however since it fails there is no receipt file created, so in the end it fails... as a workaround what I usually do is install on my personal laptop and then send a zip of .krew with all the exec there, and again copy the execs from the store to the bin, since symlinks fail... this is less than ideal

I would say it would be fairly simply to implement a proper mode for this... instead of symlink, create a copy with the version associated. It would of course be a lot larger than using the symlinks since we would have duplicates of the execs, but at least it would work.

[Voigtus]

Hai there,
I've got the same problem as @webmutation has.
We are not allowed to run elevated processes (except for a few lucky guys) and are therefore not capable to use krew.

If I remember correctly scoop is using the mechanism mentioned by @webmutation. While updating there is a "new" folder and as the last step everything is copied to a "current" folder.
This could be a "last ditch" method, when the symlinking fails.

Well at least it could make some Windows User pretty happy 😊

[ahmetb]

@corneliusweig I agree with the problem, it doesn't seem there will be a clean solution. However, right now it won't be feasible to copy all plugins’ files into ~/.krew/bin (as it'll turn into a DLL hell, will overwrite other plugins’ files/.dll's). What’s a proper solution here? Hardlinks? *.lnk shortcut files?

/priority P2

[alexm-sky]

Hey it's been a few years but I'd like to add my experience here. I'm running WSL so I have Krew working there but I'd also like to get it running on Windows.

Using Krew version v0.4.4 on Windows 10 Version 10.0.19045 Build 19045. I am able to use admin rights but it's a corporate machine with unknown policies applied.

Running the installation process (with admin CMD) results in errors for symlink creation

>krew-windows_amd64.exe install krew
Updated the local copy of plugin index.
Installing plugin: krew
W1123 12:53:59.180836   30028 install.go:164] failed to install plugin "krew": install failed: failed to link installed plugin: failed to create a symlink from "C:\\Users\\MyUser\\.krew\\store\\krew\\v0.4.4\\krew.exe" to "C:\\Users\\MyUser\\.krew\\bin\\kubectl-krew.exe": symlink C:\Users\MyUser\.krew\store\krew\v0.4.4\krew.exe C:\Users\MyUser\.krew\bin\kubectl-krew.exe: A required privilege is not held by the client.
failed to install some plugins: [krew]: install failed: failed to link installed plugin: failed to create a symlink from "C:\\Users\\MyUser\\.krew\\store\\krew\\v0.4.4\\krew.exe" to "C:\\Users\\MyUser\\.krew\\bin\\kubectl-krew.exe": symlink C:\Users\MyUser\.krew\store\krew\v0.4.4\krew.exe C:\Users\MyUser\.krew\bin\kubectl-krew.exe: A required privilege is not held by the client.

Then when I manually copy the executable to .krew\bin\krew.exe and .krew\bin\kubectl-krew.exe I get an error when running Krew even though I'm using the latest version:

>kubectl krew version
This version of Krew is not supported anymore. Please manually migrate:
1. Uninstall Krew: https://krew.sigs.k8s.io/docs/user-guide/setup/uninstall/
2. Install latest Krew: https://krew.sigs.k8s.io/docs/user-guide/setup/install/
3. Install the plugins you used
krew home outdated
Error: exit status 1

I'm not sure where to go from here to get it working.

[Basssiiie]

Any update on this? I've just given up on installing Krew again on my company Windows machine. 🤔

• We use separate admin accounts, so $home for my regular account is different from $home for my admin account. This means if I want Krew in my regular account's $home, I need to override KREW_ROOT before installation.
• Kubectl is installed in my regular account (via winget), so Krew cannot even find it if its run from a CLI with admin permissions.
• None of my other dev tools require admin priviliges to run. None of my other CLI tools require it either.
• And if a program requires admin priviliges for installation, it prompts me to login to my admin account instead of just spitting out errors.