Skip to content
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

Closed
varosi opened this issue Dec 28, 2017 · 8 comments
Closed

Sandboxed Execution proposal #3717

varosi opened this issue Dec 28, 2017 · 8 comments

Comments

@varosi
Copy link

varosi commented Dec 28, 2017

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.

@borsboom
Copy link
Contributor

borsboom commented Dec 28, 2017

I think stack build does what you're asking for. For example:

$ rm ~/.local/bin/hpack

$ which hpack || echo hpack not on PATH
hpack not on PATH

$ stack exec -- hpack --version
Executable named hpack not found on path: ["/Users/manny/.stack/global-project/.stack-work/install/x86_64-osx/lts-10.1/8.2.2/bin","/Users/manny/.stack/snapshots/x86_64-osx/lts-10.1/8.2.2/bin","/Users/manny/.stack/compiler-tools/x86_64-osx/ghc-8.2.2/bin","/Users/manny/.stack/programs/x86_64-osx/ghc-8.2.2/bin","/Users/manny/.nix-profile/bin","/Users/manny/.nix-profile/sbin","/Users/manny/.eb-dotfiles/bin","/Users/manny/.local/bin","/Users/manny/bin","/usr/local/bin","/usr/bin","/bin","/usr/sbin","/sbin","/opt/X11/bin"]

$ stack build hpack
[snip]
hpack-0.21.2: configure
hpack-0.21.2: build
hpack-0.21.2: copy/register
Completed 44 action(s).

$ stack exec -- hpack --version
hpack version 0.21.2

$ stack exec which hpack
/Users/manny/.stack/snapshots/x86_64-osx/lts-10.1/8.2.2/bin/hpack

$ which hpack || echo hpack not on PATH
hpack not on PATH

@kadoban
Copy link
Collaborator

kadoban commented Dec 28, 2017

If you want "sandboxing" like this by GHC version, that's exactly what the --copy-compiler-tool flag does on stack build. So if you do stack build ghc-mod --copy-compiler-tool it should be available via stack exec -- ghc-mod exactly when you're in a context with the same GHC version.

@mgsloan
Copy link
Contributor

mgsloan commented Dec 28, 2017

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.

@mgsloan mgsloan added this to the Support milestone Dec 28, 2017
@varosi
Copy link
Author

varosi commented Dec 28, 2017

Great! I didn't know that!

@varosi
Copy link
Author

varosi commented Dec 29, 2017

I found one issue with that:

  1. stack build --copy-compiler-tool ghc-mod
  2. Go and delete ghc-mod.exe into C:\sr\snapshots\726bcf65\bin\
  3. stack build --copy-compiler-tool ghc-mod

Instead of building another one and then copy, it showed that error:

Couldn't find executable ghc-mod in directory C:\sr\snapshots\726bcf65\bin\

@mgsloan
Copy link
Contributor

mgsloan commented Dec 29, 2017

@varosi True, that is an issue tracked by #3083

@varosi
Copy link
Author

varosi commented Dec 30, 2017

Thanks!

@mgsloan
Copy link
Contributor

mgsloan commented Jan 2, 2018

Welcome! :D Sounds like this can be closed.

@mgsloan mgsloan closed this as completed Jan 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants