Erroneous detection of Stack projects
chris-martin opened this issue · 9 comments
Apologies as usual if this is an outdated issue or the wrong project; I'm encountering this problem via several levels of indirection (vscode haskell plugin, haskell-language-server, ...) and so I do not know exactly the infrastructure or how to detect what relevant versions of things are. I recently upgraded to NixOS 22.11 and have experienced this regression.
I have had to go back to placing this hie.yaml
file in all of my repositories:
cradle:
cabal:
My projects all have a cabal.project
file, and none of them has a stack.yaml
file. But the IDE has regressed to perpetually trying to use Stack, which I don't even have installed, unless this hie.yaml
is present.
Thanks for the bug report!
This is most likely caused by implicit-hie which is an additional indirection for cradle detection.
hie-bios in HLS performs no auto-detection at all.
My investigation shows that 1.8.0.0 was using implicit-hie 0.1.2.7 most likely. 1.9.0.0 was using 0.1.4.0 most likely.
The only code difference seems to be these two:
According to @Avi-D-coder, 0.1.2.7 and 0.1.4.0 (0.1.4.0 is a re-publish of 0.1.2.7) are the same version, so it might be a longer standing issue even.
Also, @hasufell, since @chris-martin is using nixpkgs, nixpkgs follows stackage and stackage included the version for at least a couple days, it is actually possible that the nixpkgs version ships with version 0.1.3.0.
Additionally, our buildplan in HLS always excluded 0.1.3.0.
@chris-martin can you share your exact project or at least the whole file-tree?
Here is one example project:
typeclasses/ascii-char@f6e082f
-
fish> cd (mktemp -d) fish> git clone https://github.com/typeclasses/ascii-char.git fish> code ascii-char
-
Open
ascii-char/library/ASCII/Char.hs
-
VSCode launches and displays a popup that says:
Failed to find executable "stack" in $PATH for this Stack project.
From the "output" tab:
2023-01-16 19:31:56.6420000 [client] INFO Finding haskell-language-server
2023-01-16 19:31:56.6520000 [client] INFO Searching for server executables haskell-language-server-wrapper,haskell-language-server in $PATH
2023-01-16 19:31:56.6520000 [client] INFO $PATH environment variable: [ ... ]
2023-01-16 19:31:56.6570000 [client] INFO Found server executable in $PATH: haskell-language-server-wrapper
2023-01-16 19:31:56.6570000 [client] INFO Activating the language server in working dir: /tmp/tmp.hrkhUBUv8T/ascii-char (the workspace folder)
2023-01-16 19:31:56.6570000 [client] INFO run command: haskell-language-server-wrapper --lsp
2023-01-16 19:31:56.6570000 [client] INFO debug command: haskell-language-server-wrapper --lsp
2023-01-16 19:31:56.6570000 [client] INFO server environment variables:
2023-01-16 19:31:56.6610000 [client] INFO Starting language server
No 'hie.yaml' found. Try to discover the project type!
Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) Version 1.8.0.0 x86_64 ghc-9.0.2
Current directory: /tmp/tmp.hrkhUBUv8T/ascii-char
Operating system: linux
Arguments: ["--lsp"]
Cradle directory: /tmp/tmp.hrkhUBUv8T/ascii-char
Cradle type: Stack
Tool versions found on the $PATH
cabal: 3.8.1.0
stack: Not found
ghc: 9.4.2
Consulting the cradle to get project GHC version...
Failed to find executable "stack" in $PATH for this Stack project.
2023-01-16T19:31:57.408554Z | Info | Starting server
2023-01-16T19:31:57.413383Z | Error | LSP: no handler for: SInitialized
2023-01-16T19:31:57.414057Z | Error | LSP: no handler for: SWorkspaceDidChangeConfiguration
2023-01-16T19:31:57.414425Z | Error | LSP: no handler for: STextDocumentDidOpen
Perhaps haskell-language-server ought to be printing version numbers for more of its dependencies.
Also perhaps implicit-hie should confine its selection to only the tool stacks which are installed on the system?
Perhaps haskell-language-server ought to be printing version numbers for more of its dependencies.
Hard agree on that
Is this still relevant or did a subsequent release fix this?
I haven't seen the issue in a while, will reopen if it recurs.