Support multiline script interpreter directive for better readability

[harendra-kumar]

When we have many packages to be specified on the embedded stack command the comment line can become too long. It would be nice to support a multiline comment so that it can formatted for better readability. Like this:

{- stack --verbosity silent 
         --resolver lts-3.14 
         --install-ghc runghc 
         --package system-filepath 
         --package system-argv0 
         --package random 
         --package argparser
         ...
-}

Further comments from the stack mailing list:

Perhaps {-# OPTIONS_STACK ... #-} would be a more standard syntax for it?

I'd worry about that being confused with compiler pragmas, and people expecting to to be used in all cases (i.e. by stack build as well). Since this only applies when using stack as a script interpreter, that would be misleading.

[mgsloan]

I agree, this would be nice. Feel free to open a PR implementing it.

[borsboom]

This is especially important if we want to have a --explicit-packages flag as mentioned in #1388 (and related to #1208). That package list is likely to be quite long which would be unwieldy with the current single-line approach.

[harendra-kumar]

I am assuming we are keeping the current comment format starting with "--" as well. This is useful for the common case of shorter commands.

A few minor points regarding the interpreter implementation:

• The current implementation requires a space after "--". We can relax that to make the syntax more permissive rather than documenting the nuances.
• We should make it clear in the documentation that the comment should immediately follow the shebang line. No blank lines are allowed in between.
• Currently stack prints some output of its own before running the script:

Run from outside a project, using implicit global project config
Using resolver: lts-3.14 from implicit global project's config file: /var/home/harendra/.stack/global-project/stack.yaml

When used as interpreter no other output is desirable other than the script's output itself. In fact this should hold true for any stack exec command. That might interfere with the processing of the script output.

• --install-ghc could be a bit time consuming operation and a largish download. How about a command line option to ask the user - something like --install-ghc=ask?

[mgsloan]

• The current implementation requires a space after "--". We can relax that to make the syntax more permissive rather than documenting the nuances.
• We should make it clear in the documentation that the comment should immediately follow the shebang line. No blank lines are allowed in between.

Agreed on both points.

When used as interpreter no other output is desirable other than the script's output itself. In fact this should hold true for any stack exec command. That might interfere with the processing of the script output.

It may be problematic to support this given --install-ghc. One thing that might be helpful is that all that info logging goes to stderr, so if you only care about the stdout of a script, things will work fine.

--install-ghc could be a bit time consuming operation and a largish download. How about a command line option to ask the user - something like --install-ghc=ask?

So far, stack hasn't added much interactivity, in order to make it easily scriptable. We don't necessarily need to stick to this principle everywhere, though, this seems like a reasonable thing to have.

[soenkehahn]

Regarding stack adding output: I would prefer if stack told me when it has to download something, be it ghc or packages from hackage. Or if it has to compile a dependency. Any such output has to go to stderr (as @mgsloan said). If nothing has to be downloaded or compiled because everything is already cached in ~/.stack, I think stack shouldn't add anything, not even to stderr.

[harendra-kumar]

I agree completely.

[mgsloan]

@soenkehahn Yup, sounds good to me!

[harendra-kumar]

Another problem that I found with the implementation - if we have a file in the current directory whose name matches any of the stack commands then instead of running the command stack will execute the file as an interpreter. Here is an example:

cueball $ cat build
-- stack --verbosity silent runghc

main = putStrLn "Hello there!"
cueball $ stack build
Hello there!

[mgsloan]

@harendra-kumar Whoah, yeah, that should be fixed.