[zed] can not run, not sure it even was installed (clean msys2)

[the-Arioch]

Description / Steps to reproduce the issue

Just wanted to take a look at zed, so, assume zero experience

• Win10 x64, traces of msys there inside TortoiseGit, but i guess no "general" msys2 environment
• downloaded msys2 using UniGetUI - it installed it via SCOOP packages manager
• run pacman -Suy until it stopped doing changes, so assuming it is the actual version
• now i have 3 shortcuts with MSYS icons in the start menu, i run the "msys2", then try to install as documented

$ pacman -S $MINGW_PACKAGE_PREFIX-zed
pacman: unknown option -- z

$ echo $MINGW_PACKAGE_PREFIX-zed
-zed

• D'OH... well, i wanna native experience, so i open another shell, UCRT-tagged. Still no luck (do not remember what diagnostics exactly)
• i have to resort to opening the package directory web page, i see Binary Packages section does not list a thing for UCRT, but then it lists the immediate "literal" for the package, so finally i can run the command that works, or at least pretends to: pacman -S mingw-w64-clang-x86_64-zed

$ zed
-bash: zed: command not found

O_o

• trying with all the three shells of MSYS2, thinking them perhaps having different UNIX $path or something and it is disallowed to run mingw packages from ucrt shell - all the same

• running mingw shell

$ echo $MINGW_PACKAGE_PREFIX
mingw-w64-x86_64

• aye, we at least have some env-vars there... ls /bin - no zed-anything there. ls /usr/bin - neither and it seems to be the same symlinked folder

• opening github page with pkgfile sources... oh, wow, cargo...

$ cargo
-bash: cargo: command not found

$ ls ${pkgdir}${MINGW_PREFIX}/bin
    >>empty<<

$ echo ${pkgdir} fff ${MINGW_PREFIX}/bin
fff /mingw64/bin

$ ls /mingw64
bin  etc  include  lib  share

$ ls /mingw64/bin
    >>empty<<

so, for a while i am done with Zed

my premonitions and speculaitons go as that

• maybe your zed package only is compatible with specific ways/sources of installing MSYS2 and Scoop is not supported. Perhaps that is to be documented then, allowed ways to install MSYS2 have to be whitelisted
• it is not clear to me if you distributed binaries or build-recipes
• • users definitely expect ready to run binaries, following chocolaty and winget experience
• if you intend to build rather than download, perhaps that has to be outright documented on the Zed site, because, frankly, downloading and compiling is very different footrpint in terms of time, CPU load, disk volume, etc. I assumed installing ready to run binaries, if it is not so i should've installed all the msys2 to another physical disk (HDD with more time, rather than small system SSD)
• it would be nice if the Zed page would also tell the novices outright:
• • how should succesfull installation look like, what should be the last 3-4 lines of pacman output normally, so if they are different we instantly knew somethign went wrong
• • how are we supposed to run Zed after it was downloaded by pacman, so we would be spared of "perhaps i am too stupid to guess the proper command" F.U.D.
• i also suspect the Zed was downloaded as source tarball but never installed because of lack od dependencies, like cargo, rustup, rustc, and whatever the source libraries would be required for compiling it then
• • if that guess is correct then the package recipe also fails utterly to detect errors, pacman was sure everything installed okay. Perhaps the recipe should issu which zed or something to make sure you did install the runnable zed.exe

but i am not sure what it is inside my newly installed msys2 actually nor how to diag it (and i hate midnight commander too)

Expected behavior

there was any command to run the "installed" editor

Actual behavior

there is nothing to run or no way to know what to run

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-19045 mldev02 3.5.4-0bc1222b.x86_64 2024-09-04 18:28 UTC x86_64 Msys

MINGW environments affected

• MSYS
• MINGW64
• MINGW32
• UCRT64
• CLANG64
• CLANGARM64

[the-Arioch]

[dima-kirichenko]

$ ls /mingw64/bin
>>empty<<

and what about /ucrt64/bin? after running pacman -S mingw-w64-clang-x86_64-zed in UCRT64 i found zed.exe right there (still not being able to simply run zed in a shell though).

[the-Arioch]

and what about /ucrt64/bin?

нет пути! i tried running zed from the ucrt shell immediately after "installing" before i knew i got into troubles. But okay, i can do it again to be sure ``` ***@***.*** UCRT64 ~ $ which zed which: no zed in (/ucrt64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl) ***@***.*** UCRT64 ~ $ ls /ucrt64 bin etc include lib share ***@***.*** UCRT64 ~ $ ls /ucrt64/bin ``` so i propose you make a tabula rasa windows virtual box, WITHOUT rust/cargo/VC++BT/anything. Install there clean bare msys2, again, without any developer tools, and then try the pacman -S zed i think that is the case, you wanted to "build world" and there was no builders available Message ID: ***@***.***>

…

[ognevny]

currently Zed is available for CLANG64 only: pacman -S mingw-w64-clang-x86_64-zed. it will be installed to /clang64/bin/zed.exe

[the-Arioch]

Looks like it, i would check if that is runnable later when have time. But at least it is found. ``` ***@***.*** CLANG64 ~ $ which zed /clang64/bin/zed ***@***.*** CLANG64 ~ $ ls clang64/bin ls: cannot access 'clang64/bin': No such file or directory ***@***.*** CLANG64 ~ $ ls /clang64/bin libc++.dll libunwind.dll libzstd.dll pzstd.exe zed.exe zstd.exe ``` I still vote for adding visible output to the package sources, so user would see it, given this MSYS2 quirk of having MANY parallel dimensions. Frankly, without a priori MSYS2 experience this multiverse was not expected... Something along ``` echo "***************************************************************" echo WHICH ZED? echo `which zed` echo "***************************************************************" ``` And/or always put a symlink into `/usr/bin` for the latest installed thing ? Then, RM that link on uninstallaion. _I wonder if MSYS2 has a concept like *alternatives*. So having several installed zeds user could uniformly select one to run by default. I mean, de-installation would remove the symlink, and it is ok, user would be explicitly made known his usual editor is gone, making a "caring" loop across `/*/bin` to find some random other zed to recreate the shortcut could be confusing. But then if user could easily and uniformly query other possible installed zeds and select one as default it could be nice_

[the-Arioch]

got a minute and tried to launch it from CLANG64 MSYS

$ zed
[2024-11-01T17:42:56+03:00 ERROR fs] Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }
[2024-11-01T17:42:56+03:00 ERROR fs] Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }
[2024-11-01T17:42:56+03:00 ERROR fs] Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }
[2024-11-01T17:42:56+03:00 ERROR fs] Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }
[2024-11-01T17:42:56+03:00 ERROR fs] Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }
[2024-11-01T17:42:56+03:00 ERROR fs] Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }
[2024-11-01T17:42:56+03:00 ERROR fs] Error { kind: Generic("Input watch path is neither a file nor a directory."), paths: [] }
[2024-11-01T17:42:56+03:00 ERROR blade_graphics::hal::init] Missing Vulkan entry points: LibraryLoadFailure(LoadLibraryExW { source: Os { code: 126, kind: Uncategorized, message: "Не найден указанный модуль." } })
Zed failed to open a window: VulkanLoadingError(LibraryLoadFailure(LoadLibraryExW { source: Os { code: 126, kind: Uncategorized, message: "Не найден указанный модуль." } })).
See https://zed.dev/docs/linux for troubleshooting steps.

Why? what LoadLibraryExW for a Linux program (MSYS is quasi-virtual Linux, is it not) ?

Here i have a stub video-card merely to have 2 digital cables.
It's "current name" is Radeon R5 220 though actually it is a rather old VPU, some entry-lavel HD 7xxx AFAIR, that was produced for years renaming itself with every generation.

Driver is 26.02.2016 / 15.301.1901.0, at very least it should support OpenCL (used it to make RAM-disk inside)...

Though GPU-Z shows clear checkboxes for both OpenCL and Vulcan now (but does tick DirectCompute...).

Perhaps later i would have to play with drivers, there was some "lesser evil" choice i barely remember. Maybe it exactly was between stable but restricted and unstable but more featured versions.

Anyway, if Zed needs Windows Vulcan drivers perhaps it could, again, be documented and maybe even checked from inside pacman scripts?

Or is it again that Linux Vulcan runtime had to be installed inside MSYS?
At least it referred me to Linux troubleshooting, that hardly would describe tinkering with Windows drivers :-D

Any chances for Zed having more convensional back-ends without Vulcan? BTW, VSCode runs fine and i did never even puzzled myself which back-end it was using, i thought VPU-rendering was solved by browsers long ago before MSIE and Opera went extinct :-)

[ognevny]

can you try to update graphics card driver?

[the-Arioch]

i would check it, it is not a pressing issue, especially at work

surely i did have OpenCL-based RAM-disk, so there must've been another more or less owrking driver.

meanwhile is Zed really so "advanced" it can not operate without Vulkan 3D ? can hardly believe it...

[ognevny]

it uses Vulkan for GPUI - their own window system