Upgrading to 0.93 on Windows installs nu to a new/different location

[mazansm]

Describe the bug

winget upgrade showed an update to 0.93. Winget upgrade --all completed successfully. However, a nu -v still showed version 0.92. After some digging I discovered that instead of upgrade the version I have been using for several months now it put 0.93 into a new directory and added that directory to windows user environment variables as opposed to its previous location which was using Path from the system environment variables.
Original Location: C:\Program Files\nu\bin
New Location: C:\Users\UserName\AppData\Local\Programs\nu\bin
which nu -a displays the following.
Any info and assistance is greatly appreciated. Thanks so much!

How to reproduce

1. have nu 0.92 or previous install via winget install nu
2. Check for updates via winget upgrade
3. upgrade to listed new version of nu via winget upgrade --all

Expected behavior

I expected the same as all previous upgrade which immediately update the version i am currently using. Aka nu -v 0.92. winget upgrade --all followed immediately by nu -v would return 0.93.

Screenshots

No response

Configuration

key	value
version	0.92.2
branch
commit_hash	2a08a18
build_os	windows-x86_64
build_target	x86_64-pc-windows-msvc
rust_version	rustc 1.77.2 (25ef9e3d8 2024-04-09)
rust_channel	1.77.2-x86_64-pc-windows-msvc
cargo_version	cargo 1.77.2 (e52e36006 2024-03-26)
build_time	2024-04-10 21:24:37 +00:00
build_rust_channel	release
allocator	mimalloc
features	default, sqlite, trash, which
installed_plugins

Additional context

No response

[fdncred]

Yup, this is correct. We had to switch to a perUser msi installation versus a perMachine msi installation. It's not a bug but it's intended to run this way now.

[mazansm]

Ah OK, sounds good. I couldn't find any mention of that anywhere. Thanks for the info!
What is the best way to remove the existing system installation?
Thanks!

[fdncred]

Ya, it was a mess. We didn't have plans to do this but when winget-pkgs kept failing on release day, we had to take drastic measures and just force it to work somehow.

What is the best way to remove the existing system installation?

I'd probably uninstall it after backing up your config files. Then try to uninstall the other one if it lets you. If it doesn't let you, you should just remove the folder it was installed in.

Then once everything is uninstalled and you have your backup config files, I'd install it again to the new location and make sure the config files are in place. I'm not positive but I don't think uninstalling will disturb your config files but it's always best to be safe. Unless you're just running with default config files and if that's the case, on the first run you can regenerate them.

[Kissaki]

Same issues with 0.94.0.

Yup, this is correct. We had to switch to a perUser msi installation versus a perMachine msi installation. It's not a bug but it's intended to run this way now.

Ya, it was a mess. We didn't have plans to do this but when winget-pkgs kept failing on release day, we had to take drastic measures and just force it to work somehow.

Is this state intended to stay? (Then I would have expected this ticket to be closed, which it was not.) Is the issue tracked somewhere? Is the information what the issue is documented somewhere?

[Kissaki]

I'm not positive but I don't think uninstalling will disturb your config

Uninstall does not influence $nu.config-path nor $nu.env-path files which are stored in Roaming.

[fdncred]

Is this state intended to stay?

We don't intend on changing it right now. Per User seems to be working better so far.

Is the information what the issue is documented somewhere?

Only in the bizarre winget-pkgs errors with each prior release.