-
Notifications
You must be signed in to change notification settings - Fork 841
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
Sandboxed Execution proposal #3717
Comments
I think
|
If you want "sandboxing" like this by GHC version, that's exactly what the |
It'd also be great to have some automatic way to identify something as a compiler tool, possibly nicely mixed with #2122 . More thoughts on this here https://github.com/commercialhaskell/intero/issues/324 Marking this as a documentation / support issue, feel free to close or open PR improving docs. |
Great! I didn't know that! |
I found one issue with that:
Instead of building another one and then copy, it showed that error:
|
Thanks! |
Welcome! :D Sounds like this can be closed. |
General summary/comments
Currently there are tools, like ghc-mod, LiquidHaskell and other that link to GHC as a library and depend on exact version of GHC to work correctly. It is great pain to support different projects with different GHCs that way. Lot of great tools depend on exact GHC version.
It would be great if there is sandboxing of "stack install" based on current Stackage version (LTS) or GHC version.
I mean this:
stack install --sandbox ghc-mod
That line to install ghc-mod into special folder that is indexed by current Stackage version.
Then when you run:
stack exec -- ghc-mod
This line to add this special folder in front of the PATH, so the exact ghc-mod version compatible with the GHC is found.
Stackage version could be used (instead of GHC version) for indexing as the tool that ran may depend (be compatible) with exact versions of other installed tools.
The text was updated successfully, but these errors were encountered: