ref:

I'm almost completely new to helm, so this might be a stupid question..., but why is there a windows executable of helm (https://github.com/helm/helm/releases) if we can't use it?

I followed the steps listed at https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/ using cmd.com since that is my command line, and soon hit the error described above:

c:\srv\gitlab\datadog> helm3 2to3
Error: exec: "C:\\Users\\bjorn\\AppData\\Roaming\\helm\\plugins\\helm-2to3/bin/2to3": file does not exist

however, now, when trying to use wsl, I get:

bp@bjorn8:/mnt/c/srv/gitlab/datadog$ alias helm3=/mnt/c/bin/helm3.exe
bp@bjorn8:/mnt/c/srv/gitlab/datadog$ helm3 version
version.BuildInfo{Version:"v3.0.3", GitCommit:"ac925eb7279f4a6955df663a0128044a8a6b7593", GitTreeState:"clean", GoVersion:"go1.13.6"}
bp@bjorn8:/mnt/c/srv/gitlab/datadog$ helm3 plugin install https://github.com/helm/helm-2to3
Error: plugin already exists
bp@bjorn8:/mnt/c/srv/gitlab/datadog$ helm3 plugin list
NAME    VERSION DESCRIPTION
2to3    0.2.2   migrate and cleanup Helm v2 configuration and releases in-place to Helm v3
bp@bjorn8:/mnt/c/srv/gitlab/datadog$ helm3 2to3
Error: exec: "C:\\Users\\bjorn\\AppData\\Roaming\\helm\\plugins\\helm-2to3/bin/2to3": file does not exist
bp@bjorn8:/mnt/c/srv/gitlab/datadog$

Is this salvageable? Could there be a note in the docs (at https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) warning windows users to not try this procedure in any of the windows shells?

@thebjorn I assume you installed the 2to3 plugin outside of WSL. That's probably causing the errors due to the forward slashes in the path used in your example.

If you install the plugin from WSL it should work. This issue has good info on your problem: helm/helm-2to3#55

@marckhouzam Thanks for the info, I'm sure that will work (although I opted to just stay with helm 2 for now). Your answer seems to indicate that I'll need a parallel helm installation in WSL and that it will not be interchangeable with the one installed from cmd.exe - have I understood that correctly? If I have then I would urge you to update the docs!

@thebjorn I agree with you, thanks for raising. This need better clarification for users. I have opened the following issue for it: helm/helm-2to3#114

This seems hard to fix without requiring installation of some Bourne shell on Windows, e.g. bash from MSYS2 or Git For Windows.

Particularly because the plugins contain the shell script, so would each need extra work to support a CMD batch file or PowerShell script.

That said, if plugin authors are willing to maintain parallel install scripts for Bourne shell and PowerShell, then it should be relatively easy to fix on the Helm side.

A search on GitHub suggests we have over 300 public Helm plugins that reference $HELM_PLUGIN_DIR. It's possible that somehow most of these are not using an install hook, but certainly a lot of them are, from a brief glance, I saw only 3 out of the first 50 that used platformCommand instead of command, and did not have any hooks. (I assume the cost is that all three platform binaries and any dependencies are in the same bundle, but I didn't look any deeper than plugin.yaml)

The only way I can see forward here would be to have platformHooks like platformCommand, and make that just exec everywhere, rather than implicitly sh -c; and deprecate the current hooks. That would also make the code more internally-consistent, e.g., we can share behaviour with PrepareCommand.

The cost is that plugins need to take an action to become compatible with this, and we also cannot use hooks as a platform-agnostic fallback as we can for command, because the implicit sh -c cannot be assumed to work on Windows.

platformHooks would be great!

I also look into hybrid script. Hybrid scripts are runnable inside cmd and bash. They could be use as bootstraper to call the right script on the right platform.

See: https://stackoverflow.com/questions/17510688/single-script-to-run-in-both-windows-batch-and-linux-bash

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

This remains a reasonable important feature to implement, but it looks like no one (including me) has had the time/priority to advance it.

I have seen quite some people talk about issues with true support for Windows and that needing bash / sh for installing helm plugins is a bit annoying

Personally I don't have a windows machine so I can't even guess how the experience is

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

This remains a reasonable important feature to implement, but it looks like no one (including me) has had the time/priority to advance it.

Looks like the helm maintainer are under powered in general. There are a lot of opened topic but the maintainers did not have the time for it.

Generally speaking the maintainers have their hands full reviewing code. There are over 100 PRs in the queue. We really don’t have time to write new features ourselves.

A very large majority of helm’s functionality was written by the community.

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

This remains a reasonable important feature to implement, but it looks like no one (including me) has had the time/priority to advance it.

A lot of people still use helm on windows 😉

@TBBle could doing something like below work with less complexity than the other solutions and offload shell selection to the plugin developers and/or OS?

platformHooks:
  install:
    - os: linux
      command: ["sh", "-c", "$HELM_PLUGIN_DIR/scripts/install.sh"]
    - os: windows
      command: ["pwsh", "-c", "$HELM_PLUGIN_DIR/scripts/install.ps1"]

The commands would then be run by prog = exec.Command(hook.Command). For hook selection arch would be supported like platformCommand. If a script was being run and you wanted to use the default shell (more likely on Windows) you could just provide the script to the command. It would also be valid to not provide os to get the same behaviour as the legacy hooks. The legacy hooks would be deprecated and only run in the absence of platformHooks.

If this design (or something like it) looks good and there is enough bandwidth to review the PR I'd be happy to have a go at it as I don't think it adds much complexity.

and there is enough bandwidth to review the PR

Take a look at #10126, it may answers your question.

@jkroepke the PR author never replied to @TBBle so I'd categorise that as an abandoned PR and not a lack of maintainer input.

@stevehipwell Yeah, that was my preferred solution.

It looks like both what I thought #7117 (comment) would look like:

The only way I can see forward here would be to have platformHooks like platformCommand, and make that just exec everywhere, rather than implicitly sh -c; and deprecate the current hooks. That would also make the code more internally-consistent, e.g., we can share behaviour with PrepareCommand.

and what I was thinking in #10126 (comment):

Basically, I was mirroring the behaviour of platformCommand, and that does not prepend a shell in the command. I think having platformHooks act differently to platformCommand in this regard would be a surprising mistake.

I'm in-general not a fan of implicit shell-calls in "exec" systems; this includes things like the RUN command in a Dockerfile and the use of the Python's subprocess module too; both provide a way to not invoke an implicit shell, and this seems like an opportunity for us to remove it from Helm while introducing a new API. (One could make it optional and have a shell: True option, but I think that's more complexity added than value created. Also, I think powershell is a much better default shell choice on Windows than cmd. Admittedly, the list of things that I think are better than cmd has no upper bound).

I also liked the idea (although I didn't actually try to implement this) of sharing more code with the platformCommand implementation.

But that of course is just my opinion, for as much or as little as it's worth.

@TBBle does it matter that although closely aligned to platformCommand my proposal here uses an array instead of a string for command? I think this is a better API than a single string.

It's been a while but I think the YAML package used by Helm can support an array value mapped as a single string so potentially we could support both patterns?

Oh, I missed that difference. I personally prefer it as an array. I recognise not everyone loves the ergonomics of that, i.e. people still write RUN <string> in Dockerfile when RUN ['args'...] is right there. ^_^

Obviously the most flexible is if we have have both do both, as long as that's not maximising surprise for users, e.g., Dockerfile's RUN <string> implies a shell but ours doesn't; or making the code needlessly painful, e.g., the YAML package used in Helm can't distinguish the two forms.

This is used by plugin authors, rather than all Helm users, so some complexity to gain features is reasonable. On the other hand, just having the array format is also probably not unworkable for the target audience, no one's going to be writing dozens of these every week.

I'm not sure if the abstraction on top of go-yaml in sigs.k8s.io/yaml limits the ability to use a custom marshalling solution to solve the multi-type issue. But IMHO this is more of a nice to have than an essential feature.

platformHooks would be great!

I also look into hybrid script. Hybrid scripts are runnable inside cmd and bash. They could be use as bootstraper to call the right script on the right platform.

See: https://stackoverflow.com/questions/17510688/single-script-to-run-in-both-windows-batch-and-linux-bash

I got a working solution for my plugin by creating a hybrid hook script as mentioned in the stackoverflow link above which works fine for me.

:; if [ -z 0 ]; then
  @echo off
  goto :WINDOWS
fi

# ***********************************************************
# * This script is runnable on windows with cmd and linux with bash
# * cmd will ignore lines that start with :;
# * See https://stackoverflow.com/questions/17510688/single-script-to-run-in-both-windows-batch-and-linux-bash
# * and https://github.com/helm/helm/issues/7117
# *
# * The script must have LF line separator and must have extension *.cmd
# * git update-index --chmod=+x bin/install-tools-hook.sh.cmd
# ***********************************************************

# bash stuff
echo "Installing for Linux"
${HELM_PLUGIN_DIR}/bin/install-tools.sh
exit

:WINDOWS
:: windows stuff
echo Installing for Windows
%HELM_PLUGIN_DIR%\bin\install-tools.cmd

This script the executes the windows/linux specific install-tools.xxx script to install the required tools.

It is the uses as hook in plugin.yaml

hooks:
  install: "$HELM_PLUGIN_DIR/bin/install-tools-hook.sh.cmd"
  update: "$HELM_PLUGIN_DIR/bin/install-tools-hook.sh.cmd"

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

People still insist on using helm on windows.

Here a manual way to get plugins working which are just copying a binary in the helm plugin folder.

Example for helm-images plugin:

1. Execute helm plugin install https://github.com/nikhilsbhat/helm-images which will fail
   a. This step will only checkout the repo in your helm plugin directory which is still needed for the plugin.yaml (maybe just copying the plugin.yaml manually is also enough)
2. Then go to the Plugin Release page and download the required Windows binary.
   a. E.g.: https://github.com/nikhilsbhat/helm-images/releases
   b. If the plugin is not released on github then maybe check the install scripts where it fetches the release from.
3. Create a bin folder in your helm-images plugin directory and extract the downloaded binary to it
   a. For me it was under ~\AppData\Roaming\helm\plugins\helm-images\bin
4. Fix the plugin command configured in helm\plugins\helm-images\plugin.yaml
   a. Ajust the command to: command: "$HELM_PLUGIN_DIR\\bin\\helm-images.exe"
5. Plugin should work now:

PS C:\LocalData\test> helm images
  images [command] [flags]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  get         Fetches all images those are part of specified chart/release
  help        Help about any command
  version     Command to fetch the version of helm-images installed

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

And yet, people still insist on using helm on windows.

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

/not-stale

I've opened #12962 to address this.

@TBBle if you're still interested in this area would you mind taking a quick look?