-
Notifications
You must be signed in to change notification settings - Fork 845
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
Provide binaries for haskell-language-server
#6617
Comments
Using stack with ghcup is not error prone at all. GHCup will make sure that GHC and HLS are ABI compatible, which is non-trivial. A few caveats:
This is already the case when you configure stack to use the ghcup install hook (you're asked during ghcup bootstrap if you want to do so). Additionally, ghcup has an interface to correctly build HLS from source (now even in the TUI). What's the reason to duplicate this effort? |
@hasufell thanks for chiming in.
I want the option to produce statically linked binaries that are self-contained and I'm not prepared to consider (L)GPL3 dependencies at this point. That's why I originally decided on using Before going into technical stuff, are you in principle willing to consider relicensing (parts of) ghcup under MIT, BSD2 or BSD3?
That's nice, but I think not essential when you want to produce consistent environments programmatically. That's what I am doing, and I think that's what If you want to stick with LGPL3 for ghcup itself, maybe it could be an option to move some of the less UI centric code into a separate dependency (e.g. Another benefit of this approach would be a smaller dependency footprint for |
I don't think you'll be linking against ghcup in any way. Stack doesn't either. It invokes I don't see how that causes licensing issues. |
@hasufell I emphasized the relevant part of my original reply 😉 I hope that makes more sense now. If not, then please let me know and I'm happy to clarify. |
Yeah. Your answer is unclear. If you want a statically linked HLS, then that's actively discouraged (issues with TH and internal linker... we don't link dynamically for fun). Using ghcup in a toolchain that produces statically linked binaries is a non-issue in terms of license. |
Yeah, that makes sense of course. If I were linking statically against HLS, then I would not need a tool to manage HLS versions. Let me reiterate my use case:
Specifically, I'm using EDIT: So for my specific use case, what I'm looking for is a library that can manage GHC versions and corresponding HLS versions. This could either be |
You still haven't explained how that causes licensing issues with ghcup. Stack the library executes a shell hook that it knows nothing about. That shell hook may execute ghcup or anything else. Stack doesn't know. Executing a binary doesn't make you subject to LGPL. |
@hasufell to value your and my time, and to keep this issue focused, can I get your perspective on this? |
My perspective depends on the use case. I can not see a case where LGPL is a problem, since no one ever has linked against GHCup the library. |
That's great! Does this mean that if somebody wanted to use
At least from my perspective reducing this code duplication, where it makes sense, could be beneficial to all parties. A nice benefit here would be, that if you were to use both |
It's a lot of work. I'd have to contact all code contributors. So it depends.
Yes, that's tracked here: haskell/ghcup-hs#719
I find this a bit hard to understand. But I think there may be some assumptions that are not true. E.g. stack and ghcup will not magically pick the same GHC bindist. Stack inspects the system (e.g. However, ghcup allows to use stack's setup-info metadata and will then switch to stack's bindist selection logic. Both strategies can be seen here: https://github.com/haskell/ghcup-hs/blob/master/lib/GHCup/Platform.hs |
Reading through https://github.com/commercialhaskell/stack/blob/d9165e1cfc7a7738145f122f34466d0fa5b9835f/doc/Stack_and_VS_Code.md this sounds complicated and error prone.
Stack already provides GHC binaries and I think if Stack were to provide corresponding
haskell-language-server
binaries for each version of GHC, this could make things much more robust.In an ideal world a sub command, e.g.
stack lsp
would start a language server, taking care of all the details.In a second step https://github.com/neovim/nvim-lspconfig, https://github.com/haskell/vscode-haskell, etc. could then be updated to make use of
stack lsp
.Note that personally I don't have a need for
stack lsp
myself, but I do have a need for thehaskell-language-server
binaries. I have a use case where I usestack
to install versions of GHC and I'm going to need correspondinghaskell-language-server
binaries.The text was updated successfully, but these errors were encountered: