Add cabal scripting support #5483
Conversation
Nice! Needs docs though. |
0a5aea3
to
b26a029
I tried this with a multi-module script and got the following error:
In the
|
That’s not something I even considered on the docket. Easy enough to implement I suppose. |
|
||
:: | ||
|
||
$ cabal new-run script.hs |
23Skidoo
Aug 1, 2018
Member
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
.
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
Aug 2, 2018
Author
Collaborator
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.
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.
#!/usr/bin/env cabal | ||
{- cabal: | ||
build-depends: base ^>= 4.11 | ||
, shelly ^>= 1.8.1 |
23Skidoo
Aug 1, 2018
Member
Probably needs default-language: Haskell2010
as well, since otherwise you always get a warning. Unless we decide to splice that in automagically.
Probably needs default-language: Haskell2010
as well, since otherwise you always get a warning. Unless we decide to splice that in automagically.
hvr
Aug 1, 2018
Member
@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 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
Aug 1, 2018
Member
What about multi-file scripts? Easier to set default-language
in one place than use a pragma in each file.
What about multi-file scripts? Easier to set default-language
in one place than use a pragma in each file.
hvr
Aug 1, 2018
Member
@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...
@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
Aug 1, 2018
Author
Collaborator
It skips that check on purpose.
It skips that check on purpose.
23Skidoo
Aug 2, 2018
Member
Won't we then need to parse LANGUAGE
pragmas to make sure that they are actually specified when default-language
is absent?
Won't we then need to parse LANGUAGE
pragmas to make sure that they are actually specified when default-language
is absent?
@23Skidoo any objections to cherry picking this to 2.4? |
@hvr What about the spec-version thing? |
@23Skidoo well, technically this is still all a tech-preview in 2.4, thanks to the 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 OK, sure, let's backport this to 2.4. |
Where is the documentation for this feature? |
Is there any documentation on that this |
There are a couple of immediate issues I found:
|
Closes #3843. Implements effectively the design given, with some changes:
cabal new-run
allows the user to run scripts in files without shebangs{- cabal: -}
syntax is now that of the executable blockPlease include the following checklist in your PR: