-
-
Notifications
You must be signed in to change notification settings - Fork 367
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
support for cabal/stack scripts #111
Comments
Supporting cabal script is a matter of implementing the issue: haskell/cabal#6149 That is why stack scripts are already supported via hie-bios. I started to implement it, but there are a few roadbumps that makes it not as easy as hoped. |
As commented in https://github.com/haskell/ghcide/issues/162 and here, there is a workaround to make stack scripts work: Stack scripts work in a "hacky" way.
Works fine for loading and modifying the stack script. The reason this works is that you can do stack repl File.hs and the session is loaded correctly. by @fendor |
Related issue in hi-bios: haskell/hie-bios#217 |
Afaik, |
FWIW, I have been making a lot of use of Cabal scripts, using If it weren't for haskell/cabal#6999 things would actually be rather nice. |
Would it be better to create a new combined issue for GSOC? |
Mmm not sure being only 2, it is clear in each one that are related |
I ve just see the stack issue linked by @Martinsos, afaik it would enable again the workaround |
haskell/cabal#6149 has just landed (there hasn't been a release yet, though). Does that mean support for Cabal scripts could be added now? |
@rihardsk we have to look into it, but depending on the actual implementation, it could work now out of the box, assuming you have a cradle:
cabal: right next to it. You can help checking it out, by installing cabal HEAD and adding the aforementioned |
@fendor it doesn't seem to work out of the box. I built cabal HEAD and prepended it to $PATH. I also created the #! /usr/bin/env cabal
{- cabal:
build-depends:
base ^>= 4.14
, random-fu ^>= 0.2.7.7
, mwc-random ^>= 0.15.0.2
, split ^>= 0.2.3.4
, pipes ^>= 4.3.16
-}
-- ... in the header, hls fails to start and i get the following output in the
I checked that the new |
Thank you for the report! Sounds like |
Thank you! This actually worked for me wit |
@dschrempf At the current time, the EDIT: Also, I amazed to hear it works, awesome! |
I understand that hls needs this information. But the file could be a fallback or so? |
A fallback for what case? It is optional, but for cabal scripts, HLS currently has no way of determining that the given file is a cabal script (we could parse the bang line I suppose) to guess correctly what to use to load the script. |
Well, I do not know how HLS determines the file type, libraries etc. But from an outsider's point of view it seems pretty stupid that I have to provide a file that has essentially no information in it to make things work 😄. The only point in having the |
It does have information, namely that it is a file that can be loaded via cabal. You could also have a stack project, a stack script, or a plain Haskell script as well. It is not trivial to know and
No, |
I see. In thin case I advocate for improving the discovery mechanism. Thanks for explaining things to me! |
Not working for me unfortunately, with the same tools (Cabal 3.8.1.0, Linux).
I think "useless" is an exaggeration, as @fendor has said, but I agree that we should strive to make it unnecessary. I was also going to suggest parsing the bang line. There are potentially a lot of edge cases, but recognising |
It could be that this works for me because the script is within a project that provides the required libraries. |
Just to confirm, no one's actually got this to work properly by specifying a So does that mean we're still blocked on haskell/cabal#7500? Or is there, in principal, some easy way to extract the environment information from |
The former can be fixed via the linked PR. |
I think the reason for the confusion above is that, in addition to the So loading scripts does now work, though the workarounds required are quite inconvenient if one has a lot of scripts. |
Certain upcoming features (repl, runghc) are likely to make cabal scripts a much more attractive option.
I, for one, would like to switch all of my
turtle
scripts to use them, rather than (as at present) having them all in a single cabal project. But I wouldn't want to lose the IDE support...Would there be any major difficulty in supporting these? Is this actually more of a question for
hie-bios
?The text was updated successfully, but these errors were encountered: