interpreter: Don't make cached packages available that are not specified with `--package`

[soenkehahn]

Consider the following script:

#!/usr/bin/env stack
-- stack --resolver lts-3.10 --install-ghc runghc

import Safe

main :: IO ()
main = do
  print $ headMay "foo"

This script depends on the package safe. It currently works without problems on my machine, but only because I already have the package safe cached for the specified snapshot. On machines where the package is not installed it fails with

Test.hs:4:8:
    Could not find module ‘Safe’
    Use -v to see a list of the files searched for.

It would be great if stack scripts would either fail or succeed independent of cache state. Then I could create stack scripts on my machine, copy them to different machines and be fairly sure that they will run.

[borsboom]

There's a tension between making scripting as convenient as possible for "one-offs" and making them reproducible. My inclination is to lean toward the "one-off" case for this, and recommend making an actual project if you want proper reproducibility. I already find the -- stack ... header line gets unwieldy, and having to list all dependencies there would be much worse.

If we do want proper reproducible scripts, I think we'd have to considering adding support for an inline stack-yaml-like configuration in the script's header, rather than reproducing a bunch of those features on the command-line. But is it worth it? I'm inclined to think not.

[soenkehahn]

I didn't really consider the use-case of one-off scripts, but that's a very good point.

Ideally I think we would have both: reproducible and one-off scripts. (This could be done with a command line switch or a separate command.) Any thoughts on this?

[borsboom]

No objection to finding a way to optionally improve reproducibility for scripts. Simplest might be be to add a switch to stack runghc that requires dependencies to be explicitly listed.

[borsboom]

Note discussion of multiline script directive in #1394, which should probably be done before this.

Also, related discussion about adding a --standalone flag in #1388 (comment).