Add support for (some) cabal.project-fields to cabal script-metadata

[hvr]

The basic script feature (see #3843) implemented has support for including package-description/buildinfo fields but didn't yet implement support for project metadata.

At the very least fields such as index-state, with-compiler, allow-{newer,older} and constraints shall be supported as exemplified in the example below

#! /usr/bin/env cabal
{- cabal:
index-state: 2016-09-15T12:00:00Z
with-compiler: ghc-8.0.2
allow-newer: shelly:base
constraints: filepath==1.4.1.1, containers==0.5.7.1, Cabal installed, cryptonite -none

build-depends: base ^>= 4.9
             , shelly ^>= 1.6.8
-}

main :: IO ()
main = do
   ...

/cc @typedrat

[phadej]

allow-newer

[23Skidoo]

We should also think about the backwards compat story for {- cabal: blocks while we're at it.

[hvr]

@phadej good catch!

@23Skidoo cabal: afaik is versioned; i.e. it's actually {- cabal:[<script-spec-version>] (and the spec ver is optional)

[23Skidoo]

@hvr

cabal: afaik is versioned; i.e. it's actually {- cabal:[<script-spec-version>] (and the spec ver is optional)

Is it documented somewhere which script-spec-version is the implicit one?

[23Skidoo]

Not against this proposal, but wouldn't something like

#! /usr/bin/env cabal --allow-newer=foo,bar,baz

work too?

[hvr]

@23Skidoo Unfortunately, what is allowed under POSIX for portable shebang scripts is very limited; see https://en.wikipedia.org/wiki/Shebang_(Unix)#Portability for the sad story

TLDR: the answer is "no" :-)

[23Skidoo]

okay.jpg

[cartazio]

does this require the file be named Main.hs or have a module main? (i'm kinda interested in just making sure its easy to check / validate them?)

[maoe]

+1 to this feature. I also would like to be able to set verbose: 0 to suppress build messages.

[fendor]

@23Skidoo

Is it documented somewhere which script-spec-version is the implicit one?

According to the code:
https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/CmdRun.hs#L473
It looks like 2.2

And according to the parsing of the script-block: https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/CmdRun.hs#L379
It uses the latest cabal-spec-version for parsing. Not sure if this means that it actually cant be overriden.
It seems the current parser for meta-data allows anything that can be written in an executable stanza (it is actually possible to provide a main-is field, but it is overriden later on without warning).

Using the parser for cabal.project and automatically writing it to the same fake-package seems rather easy to me! Are there more complex interactions that I should be aware of?

---

EDIT: the syntax cabal:[<cabal-spec-version>] does not seem to parse.

[gbaz]

I think that rather than altering the grammar for this bloc (which now simply obeys a portion of cabal file grammar) we should just add another config bloc that obeys cabal.project/cabal.config grammar. (the former is I believe a superset of the latter). This should be much easier to implement.

[bacchanalia]

How do we feel about the following syntax?

{- cabal:
executableFields: vals

-- cabal.project:
projectFields: vals
-}

I think it looks clean, but might be confusing because -- project: looks like a comment.
It also has the disadvantage that comments are valid inside of the block.

Alternate:

{- cabal:
executableFields: vals

cabal.project
projectFields: vals
-}

Should the header be cabal.project or just project?

[gbaz]

I lean towards project as the header.

I was actually thinking two blocs entirely as in

{- cabal:
executableFields: vals
-}

{- project:
projectFields: vals
-}

[cartazio]

That split sounds good to me. Less likely to break preexisting codes that take advantage of the scripting support too? (Which probably don’t exist but it’s nice to dream)

…

On Fri, Feb 18, 2022 at 11:40 AM gbaz ***@***.***> wrote: I lean towards project as the header. I was actually thinking two blocs entirely as in {- cabal: executableFields: vals -} {- project: projectFields: vals -} — Reply to this email directly, view it on GitHub <#5698 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQTXQFF7PRE5ZAQL4LTU3ZZBRANCNFSM4GFG6HVA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>