Skip to content

Manually building via stack / documentation issue #3182

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Philonous opened this issue Sep 16, 2022 · 12 comments · Fixed by #3314
Closed

Manually building via stack / documentation issue #3182

Philonous opened this issue Sep 16, 2022 · 12 comments · Fixed by #3314
Labels
type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..

Comments

@Philonous
Copy link

According to the documentation[1], you can install haskell-language-server via stack install --stack-yaml stack-<GHCVER>.yaml. However, the ghc-versioned stack yamls have been removed in 5a6b079. There are still some stack.yaml left, specifically for lts 16 and 19, but none of them cover ghc 8.10.7 (lts 18), which should be supported according to [2]. I've tried adjusting stack-lts19.yaml for lts-18 but find myself stuck in a tangle of incompatible library versions.

So the documentation needs to be updated to reflect the new way to manually build haskell-language-server for specific ghc versions

Also (and this isn't really part of the issue), the reason I'm trying to build it manually in the first place is that I can't for the life of me figure out how to install a specific version (commit) of haskell-language-server using nix (or home manager). Any pointers would be appreciated.

@Philonous Philonous added status: needs triage type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. labels Sep 16, 2022
@pepeiborra
Copy link
Collaborator

Apologies for the outdated documentation. It would be really nice if you could send a PR!

@Philonous
Copy link
Author

I would love to, but the problem was I couldn't figure it out myself, sorry 😅

@michaelpj
Copy link
Collaborator

I think we should maybe just remove that section of the documentation? We're moving away from maintaining stack build configurations, so we shouldn't recommend that people build it that way.

@sjshuck
Copy link

sjshuck commented Sep 27, 2022

We're moving away from maintaining stack build configurations

Yikes. Tell me what I'm wrong about:

  • Many people use Stack to build their projects
  • HLS at runtime is very sensitive to ABI compatibility, so that whatever toolchain is used to build a developer's projects, that toolchain must match that that was used to build HLS
  • Stack likes to install its own GHC
  • HLS binaries are built against those installable by GHCup
  • Stack users in general must use GHCup to install toolchain and set system-ghc: true in every stack.yaml.

If so, I will do this, and I imagine other Stack users who love HLS will do this also. But it should be stated in the documentation (is it already?) that this is the happy path, not merely a workaround for an error message. Users should be discouraged from using Stack-installed toolchain if they want to use HLS.

@pepeiborra
Copy link
Collaborator

@hasufell does that look right to you?

@hasufell
Copy link
Member

hasufell commented Sep 28, 2022

Stack users in general must use GHCup to install toolchain and set system-ghc: true in every stack.yaml.

Not true anymore (the system-ghc: true part), see https://discourse.haskell.org/t/ann-stack-2-9-1/5078/5?u=hasufell

@sjshuck
Copy link

sjshuck commented Sep 28, 2022

Not true anymore

I dunno @hasufell , I just installed GHCup for the first time and it asked me to configure Stack for HLS integration and I said yes and it put that hook in my ~/.stack dir, but Stack still tries to grab GHC unless I also add system-ghc: true.

My point is, you can't introduce HLS into a working Stack-first setup at all anymore. You have to back way up and install GHCup and let it drive the rest of your toolchain config, at least the GHC part of it. But the docs say "If you are using ghcup" and I'm saying, no, not "if"—you need GHCup, it isn't orthogonal to Stack as just another option.

Does this make sense? GHCup is a general requirement for HLS unless other configurations are supported, other configurations being just one: a Cabal-based system where GHCup isn't installing GHC and you are willing to build HLS from source. That should be spelled out.

@hasufell
Copy link
Member

but Stack still tries to grab GHC unless I also add system-ghc: true

That's either a bug or misconfiguration.

File a bug: https://gitlab.haskell.org/haskell/ghcup-hs/-/issues

@hasufell
Copy link
Member

commercialhaskell/stack#5888 could be related

@hasufell
Copy link
Member

@sjshuck can you try

curl --proto '=https' --tlsv1.2 -sSf https://www.haskell.org/ghcup/sh/hooks/stack/ghc-install.sh > ~/.stack/hooks/ghc-install.sh

and then this in any of your stack projects:

stack exec ghc -- -v0 -package-env=- -ignore-dot-ghci -e 'Control.Monad.join (Control.Monad.fmap System.IO.putStr System.Environment.getExecutablePath)'

@sjshuck
Copy link

sjshuck commented Sep 30, 2022

@hasufell I just removed -o pipefail to make the hook POSIX-compliant and it started working. It looks like you made the same change upstream. Thanks.

@michaelpj
Copy link
Collaborator

I think we can continue to support stack for working on HLS, but we do not maintain configurations for building it on multiple GHC versions, so we shouldn't recommend it as an installation method for users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants