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).

[rrnewton]

--standalone will be great.

In the meantime, is there any better way to test whether your script has undeclared dependencies rather than having to manually create a stack.yaml file and paste in the dependencies? For long dependency lists, this is rather tiresome because it's a different textual format... i.e. reformatting --package foo --package bar to a list in the yaml file.

Personally, I've never wanted irreproducible scripts because I hop around machines and LTS versions so much that I don't mentally have any model whatsoever of the state of my cache on a given machine.

I also wanted to throw out there that there are other reasons to use the script interpreter rather than a full stack.yaml project config:

• The interpreted code can be a lot faster to start up, especially if it's being edited frequently, like our plotting scripts.
• It's also simply a repository clutter issue for us. If we have N little scripts, promoting each one to a directory, with a .cabal and a stack.yaml is at least three more files/directories per script.

[harendra-kumar]

I provided a fix in PR #2480 . The PR provides a way to pass ghc options from interpreter command which was not possible before. It passes all specified packages explicitly on ghc command line and allows you to pass -hide-all-packages from your script which will hide any implicit packages from the pkg-db.

A syntactic sugar in the form of a runghc option can also be provided. Though it will not be any shorter compared to passing -hide-all-packages directly to ghc, it will perhaps be more intuitive. One won't have to refer to the ghc manual as well as stack manual to know how to specify ghc options to runghc. For example using --no-implicit-packages along with --packages is more intuitive than ending the command with a ghc option like this-- -hide-all-packages.

[harendra-kumar]

I also wanted to throw out there that there are other reasons to use the script interpreter rather than

You don't have to justify this :-) Haskell is a great scripting language and we should make scripting a first class feature. Maybe we can replace python with Haskell one day.