Add cabal scripting support #5483
Conversation
|
Nice! Needs docs though. |
typedrat
force-pushed
the
cabal-scripting-support
branch
from
0a5aea3 to
b26a029
Compare
|
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Probably needs default-language: Haskell2010 as well, since otherwise you always get a warning. Unless we decide to splice that in automagically.
There was a problem hiding this comment.
@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...
There was a problem hiding this comment.
What about multi-file scripts? Easier to set default-language in one place than use a pragma in each file.
There was a problem hiding this comment.
@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...
There was a problem hiding this comment.
It skips that check on purpose.
There was a problem hiding this comment.
Won't we then need to parse LANGUAGE pragmas to make sure that they are actually specified when default-language is absent?
There was a problem hiding this comment.
|
@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-runallows 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: