Add cabal scripting support

[typedrat]

Closes #3843. Implements effectively the design given, with some changes:

• cabal new-run allows the user to run scripts in files without shebangs
• The {- cabal: -} syntax is now that of the executable block

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

[23Skidoo]

Nice! Needs docs though.

[23Skidoo]

I tried this with a multi-module script and got the following error:

$ cabal-typedrat new-run Shake/Shake.hs
Resolving dependencies...
Build profile: -w ghc-8.4.3 -O1
In order, the following will be built (use -v for more details):
 - fake-package-0 (exe:script) (configuration changed)
Configuring executable 'script' for fake-package-0..
Preprocessing executable 'script' for fake-package-0..
cabal-typedrat: can't find source for Shake/Cabal in .,
[...]/dist-newstyle/build/x86_64-linux/ghc-8.4.3/fake-package-0/x/script/build/script/autogen,
[...]/dist-newstyle/build/x86_64-linux/ghc-8.4.3/fake-package-0/x/script/build/global-autogen

In the Shake/Shake.hs file I have

{- cabal:
build-depends: base, aeson ^>= 1.4, shake ^>= 0.16
other-modules: Shake.Cabal
               Shake.DBSchema
               Shake.Flags
               Shake.GetHsDeps
               Shake.NewBuild
               Shake.Oracles
               Shake.TeamCity
               Shake.Utils
ghc-options: -with-rtsopts=-I0
default-language: Haskell2010
-}

[typedrat]

That’s not something I even considered on the docket. Easy enough to implement I suppose.

[23Skidoo]

Can you please also add an example of how to pass command-line arguments to a script started with new-run? I expect something like cabal new-run script.hs -- --foo bar.

[typedrat]

That's exactly right, I thought it was regular enough with the rest of new-run that it didn't need to be called out explicitly, but you're right that it could use a mention.

[23Skidoo]

Probably needs default-language: Haskell2010 as well, since otherwise you always get a warning. Unless we decide to splice that in automagically.

[hvr]

@23Skidoo actually this makes me think of something... I think we should encode the spec-version somehow... e.g.

#!/usr/bin/env cabal
{-# LANGUAGE Haskell2010, GADTs #-}
{- cabal:2.4
build-depends: ...
-}

and we might want to tolerate not having to specify default-language w/ scripts, as default-{extensions,language} makes less sense imho for scripts, as we have actual language pragmas (I've intentionally added one in the example above), and you certainly wouldn't want to replicate those...

[23Skidoo]

What about multi-file scripts? Easier to set default-language in one place than use a pragma in each file.

[hvr]

@23Skidoo we can still support default-language; I just think we shouldn't force people to use it by emitting nasty warnings like we do for .cabal files...

[typedrat]

It skips that check on purpose.

[23Skidoo]

Won't we then need to parse LANGUAGE pragmas to make sure that they are actually specified when default-language is absent?

[hvr]

@23Skidoo depends on the semantics you want to have for scripts...

However, I suggest we postpone this design/bikeshedding issue to a followup-task in order not to hold up merging this PR; I think all @typedrat needs to do is tweaks the docs and we're ready to go?

[hvr]

@23Skidoo any objections to cherry picking this to 2.4?

[23Skidoo]

@hvr What about the spec-version thing?

[hvr]

@23Skidoo well, technically this is still all a tech-preview in 2.4, thanks to the new-* prefix... so we don't need this to be "final", no? :-)

As for what to do about the spec-version, I intend to write up a design ticket to discuss how to pin down the semantics in a robust way so that scripts don't bitrot if cabal keeps changing its semantics.

In any case, I consider the benefit of making this feature available to users in 2.4 in a tech-preview to gain more feedback & experience to outweight the potential risk of having to break those early adopters in 3.0...

[23Skidoo]

@hvr OK, sure, let's backport this to 2.4.

[hvr]

@23Skidoo turns out it's been already done via 3e6a2c4 :-)

[bgamari]

Where is the documentation for this feature?

[phadej]

@bgamari https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-run

[expipiplus1]

Is there any documentation on that this {- cabal: ... section should/can contain?

[expipiplus1]

There are a couple of immediate issues I found:

• Cabal prints out a bunch of diagnostic information to stdout! This makes it hard to use any Haskell script's stdout without having to filter the cabal stuff first.

  Resolving dependencies...
  Build profile: -w ghc-8.8.4 -O1
  In order, the following will be built (use -v for more details):
   - fake-package-0 (exe:script) (first run)
  Configuring executable 'script' for fake-package-0..
  Preprocessing executable 'script' for fake-package-0..
  Building executable 'script' for fake-package-0..
  [1 of 1] Compiling Main             ( Main.hs, /run/user/1000/cabal-repl.-25667/dist-newstyle/build/x86_64-linux/ghc-8.8.4/fake-package-0/x/script/build/script/script-tmp/Main.o )
  Linking /run/user/1000/cabal-repl.-25667/dist-newstyle/build/x86_64-linux/ghc-8.8.4/fake-package-0/x/script/build/script/script ...
  

• Scripts aren't standalone, in the example I found, they don't work in a directory which contains an unparseable .cabal file.