RFC: A new script command

[snoyberg]

I've discussed this in some part with various people, so I thought I'd get the thoughts down in writing. Currently, script interpreter usage of Stack has (IMO) three limitations:

• It's slower than just using runghc directly. Some of that is inherent: it needs to check for the presence of GHC and libraries, for example, which runghc does not. Nonetheless, there is more overhead than necessary. From my understanding, settings file checking is a significant component of this (and also likely something we don't want to impact the behavior of script usage).

• Scripts violate some reproducibility rules, because:

  • They don't require that a resolver be set
  • They don't require that all packages be listed
  • They can be impacted by other packages installed

  These trade-offs all make sense when considering the runghc feature in general, but are less appetizing when applied to reproducible scripts.

• There are multiple options that should almost always be set but aren't enforced: --install-ghc, a --resolver as implied above.

Proposal: let's add a new Stack command: stack script. It would have the following semantics:

• Require that a --resolver be set
• Hide all packages from the package database except those specified with --package. (Perhaps make an exception for wired in packages, or at the very least base.)
• Automatically imply --install-ghc
• Ignore all settings files

As an alternative (or addition) to the above, we could consider:

• Making these behaviors options available to runghc (e.g., --no-parse-settings-file)
• Don't actually add a script command, but add support to the script interpreter bits of Stack to recognize a script command and do the right thing.

[silky]

i prefer the first proposal; a new command. it will be cleaner indication that it is doing something special.

[chrisdone]

I think the script command is a good proposal, better than changing runghc.

[harendra-kumar]

Sounds good to have a packaged command since this is a common enough use case. Users will not have to scratch their head and consult documentation on what all options to specify. Making this part of runghc will not solve the complexity of too many options (we already have tricky ways to specify options, for example see #2486).

I also do not like the second alternative of a magical command only visible to interpreter, it will cause confusion.

How about using stack run or stack runsure instead of stack script? Just a quick thought.

[snoyberg]

I think stack run would be confused with cabal run, which (IIRC) builds an executable in a project and runs it.

I agree with the overall consensus that an explicit new command is better than a bunch of new options or a secret command.

[snoyberg]

I was planning on hacking on this next week, but I was a little over-anxious to hit it, so: #2806. Still needs work, but may be worth poking at to see if the functionality meets what we're all expecting.

[guibou]

Do you think a shorter way of listing packages can be introduced? Instead of including as many --package as needed, perhaps a coma separated list ? Or a special comment in the haskell file, something such as:

#!/usr/bin/env/stack
-- resolver: lts-...
-- packages: foo bar baz

[snoyberg]

@guibou I've actually set this up already such that the following works:

#!/usr/bin/env stack
-- stack script --resolver lts-7.9 --package "stm async"
import Control.Concurrent.Async
import Control.Concurrent.STM

main = putStrLn "Hello World!"

I can see advantages in both directions on your request. The current script approach is very nice, because it's a direct translation of what you'd do on the command line. There's nothing extra that needs to be learnt. On the other hand, a more explicit syntax may be nice.

Given the ability to give a space-separated (or maybe also comma-separated as you suggested? seems unobjectionable to me) list of packages, do you think that reduces the pain enough to keep the syntax as-is?

[guibou]

@snoyberg The space separated list inside --package(s) is alright.

Another feature request, script needs a way to fallback to ghci once the script is done executing (or if there is no main method). I'm always using ghci as a interface for my scripts when they need some kind of user interaction, mostly to use the auto completion, the type checker and avoid writing a CLI parser.

[harendra-kumar]

@guibou you can use stack exec ghci command in interpreter comment. See #2788 .

[guibou]

@harendra-kumar Yes but, as far as I know, it suffers from the same issues about reproducibility discussed in this thread.

[snoyberg]

I'm not following the connection between this and ghci. Keep in mind that I almost never use ghci myself, so it's almost certain I'm just missing something very obvious.