powershell-core does not provide a pwsh shim

[dorencambia]

powershell-core installs pwsh. The registry for powershell-core recently changed from asdf:daveneeley/asdf-powershell-core to defaulting to aqua:PowerShell/PowerShell and after this change, installing it with mise no longer makes pwsh available.

Using an alias to force the registry to the previous one fixes the issue, and a chmod +x "/mise/installs/powershell-core/$(mise current powershell-core)/pwsh" && mise reshim also fixes it, but this took awhile to figure out and it would be nice for it to just work without extra workarounds.

The root cause of the issue appears to originate from the PowerShell repo itself, which has ignored this bug since June. I'm not sure if it's possible to make the file executable on your end, but if it isn't, you might want to consider changing the default registry until Microsoft fixes the root issue (or perhaps until Aqua does something about it first).

[jdx]

it certainly is a bug with powershell. We had a similar issue with spotbugs recently: #4189

I think we probably could chmod -x all of the files that aqua provides us: https://github.com/aquaproj/aqua-registry/blob/139bf38101ad69c0721bcfe4cd731c21029041aa/pkgs/PowerShell/PowerShell/registry.yaml#L7-L8

though I'm not sure if all of aqua's "files" are supposed to be executable or not.

[joshriverscambia2019]

Agree that a blanket chmod on the aqua files seems likely to bite us back.

In the solution space:

1. Best would be for it to be fixed in PowerShell, but so far the maintainers have not shown a lot of urgency.
2. Getting support in Aqua for marking specific files as executable, post-processing a borked upstream install, or whatever would be the "right" place to manage the problem if we cannot rely on the upstreams to be well maintained. I definitely feel like aqua would benefit from a post-install checkout spec (report failures when the upstream doesn't have the correct permissions with a helpful message>?)
3. Having the mise registry prefer the asdf plugin to the aqua plugin for this install, at least until it gets fixed with aqua/powershell, would be an option.
4. As a generic solution, we could be using the postinstall lifecycle hooks to repair the failed install (I'm not sure that postinstall runs before the shimming...so that might need to be managed). I can see where this kind of thing could be patched in to registry.toml to workaround problems....but it would be so better to have it correctly managed by the backend.

I don't know if there are any helpful ideas in there. I greatly appreciate the tool and the velocity of improvement I've been seeing!

[dorencambia]

For what it's worth, I was considering reporting this to aqua as well, but the file actually is executable when installing through aqua (although I suppose it could still make sense to report the issue with their registry even if the real issue is upstream from them..?) I'm not really familiar with aqua, but here's some steps to show that it works in a fresh environment:

From inside the golang:latest docker image (docker run -it golang):

go install github.com/aquaproj/aqua/v2/cmd/aqua@latest
export PATH="/root/.local/share/aquaproj-aqua/bin:$PATH"
aqua init
aqua generate -i PowerShell/PowerShell
aqua install

# output starts with "lrwxrwxrwx"
ls -l /root/.local/share/aquaproj-aqua/bin/pwsh
# install a powershell dependency so pwsh doesn't print an error
apt update -y && apt install -y libicu-dev
# successfully opens a shell
pwsh

[jdx]

it seems they add it https://github.com/aquaproj/aqua/blob/a270143cf2d6faf3ac438b8254b3f847a73093a1/pkg/installpackage/check_file.go#L133-L139

so we should do the same