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]

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
-}

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

[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?

[hvr]

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

[23Skidoo]

@hvr What about the spec-version thing?

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

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

[23Skidoo]

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

[hvr]

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

[hvr]

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