prefix-dev / pixi

Package management made easy
https://pixi.sh
BSD 3-Clause "New" or "Revised" License
3.29k stars 182 forks source link

Windows: pixi self-update failed #2059

Open certik opened 1 month ago

certik commented 1 month ago

In shell:

~/repos/pixi(main)$ where pixi
C:\Users\ondrejcertik\.pixi\bin\pixi.exe
~/repos/pixi(main)$ pixi self-update
  × pixi is not installed in the default location:
  │
  │ - Default pixi location: C:\Users\ondrejcertik\.pixi\bin\pixi.exe
  │ - Pixi location detected: C:\Users\ondrejcertik\.pixi\bin\pixi.EXE
  │
  │ It can happen when pixi has been installed via a dedicated package manager
  │ (such as Homebrew on macOS).
  │ You can always use `pixi self-update --force` to force the update.

~/repos/pixi(main)$ ls ~/.pixi/bin
gtop.bat     pixi.exe  uninstall.bat  vimrun.bat
install.bat  tee.bat   vim.bat        xxd.bat
ruben-arts commented 1 month ago

Maybe this is a better issue for shell as the detected location is comming from this function:

std::env::current_exe()
wolfv commented 1 month ago

I don't think this is related to shell to be honest. It looks like it fails because of lower / uppercase EXE vs exe.

wolfv commented 1 month ago

We should compare the lowercase string/path.

baszalmstra commented 1 month ago

But only on platforms that use a case insensitive file system!

wolfv commented 1 month ago

It sounds like more of an edge case if you have two paths to pixi executables that are only different by upper-/lowercase letters ...

ruben-arts commented 1 month ago

How could it get a uppercase here? It is nowhere to be found.

certik commented 1 month ago

It's weird indeed, but the issue does seem to come from the uppercase vs lower case paths in:

  │ - Default pixi location:  C:\Users\ondrejcertik\.pixi\bin\pixi.exe
  │ - Pixi location detected: C:\Users\ondrejcertik\.pixi\bin\pixi.EXE

Why does the detection code append .EXE is not clear.

chawyehsu commented 1 month ago

I just tested and this is certainly caused by shell, and there is a great possibility it may be related to the PATHEXT environment variable on Windows.

If you run pixi.exe self-update in shell, note that explicit extension of pixi, then there won't be a .EXE.

certik commented 1 month ago

Indeed, this workaround works:

~$ pixi self-update
  × pixi is not installed in the default location:
  │
  │ - Default pixi location: C:\Users\ondrejcertik\.pixi\bin\pixi.exe
  │ - Pixi location detected: C:\Users\ondrejcertik\.pixi\bin\pixi.EXE
  │
  │ It can happen when pixi has been installed via a dedicated package manager
  │ (such as Homebrew on macOS).
  │ You can always use `pixi self-update --force` to force the update.

~$ pixi.exe self-update
✔ Pixi will be updated from 0.29.0 to 0.30.0
✔ Pixi archive downloaded.
✔ Pixi archive uncompressed.
✔ Pixi has been updated to version 0.30.0.
~$

So one fix of course is that maybe shell should use lower case .exe instead of .EXE. Sure, we can probably do that.

However, shouldn't both work on Windows?

~$ git --version
git version 2.46.0.windows.1
~$ git.exe --version
git version 2.46.0.windows.1
~$ git.EXE --version
git version 2.46.0.windows.1
~$ Git.EXE --version
git version 2.46.0.windows.1
~$

It seems the filesystem is case-preserving but case-insensitive. From https://en.wikipedia.org/wiki/Case_preservation#Case-preserving,_case-insensitive

Most of the file systems in macOS, current versions of Microsoft Windows, and all versions of Amiga OS are case-preserving and case-insensitive.

So of the three main platforms that pixi supports (Linux, macOS and Windows), only Linux is case-sensitive, while macOS and Windows both should behave the same.