Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hvr opened this issue Nov 19, 2018 · 14 comments · Fixed by #7997
Closed

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

hvr opened this issue Nov 19, 2018 · 14 comments · Fixed by #7997

Comments

@hvr
Copy link
Member

hvr commented Nov 19, 2018

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
Copy link
Collaborator

phadej commented Nov 19, 2018

allow-newer

@23Skidoo
Copy link
Member

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

@hvr
Copy link
Member Author

hvr commented Nov 19, 2018

@phadej good catch!

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

@23Skidoo
Copy link
Member

@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
Copy link
Member

Not against this proposal, but wouldn't something like

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

work too?

@hvr
Copy link
Member Author

hvr commented Nov 21, 2018

@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
Copy link
Member

okay.jpg

@cartazio
Copy link
Contributor

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

lukel97 added a commit to lukel97/cabal that referenced this issue Oct 26, 2019
Adds a new data type and field grammar for parsing script metadata.
Now it is possible to have scripts like:

    #!/usr/bin/env cabal
    {- cabal:
    build-depends: base
    with-compiler: ghc-8.6.5
    -}
    main = putStrLn "hey"

Progresses towards haskell#5698
@maoe
Copy link
Member

maoe commented Mar 30, 2020

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

@fendor
Copy link
Collaborator

fendor commented Apr 30, 2020

@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
Copy link
Collaborator

gbaz commented Feb 17, 2022

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 bacchanalia self-assigned this Feb 18, 2022
@bacchanalia
Copy link
Collaborator

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
Copy link
Collaborator

gbaz commented Feb 18, 2022

I lean towards project as the header.

I was actually thinking two blocs entirely as in

{- cabal:
executableFields: vals
-}

{- project:
projectFields: vals
-}

@cartazio
Copy link
Contributor

cartazio commented Feb 18, 2022 via email

bacchanalia added a commit to bacchanalia/cabal that referenced this issue Feb 19, 2022
bacchanalia added a commit to bacchanalia/cabal that referenced this issue Feb 27, 2022
jneira pushed a commit to bacchanalia/cabal that referenced this issue Mar 2, 2022
@mergify mergify bot closed this as completed in #7997 Mar 2, 2022
Kleidukos pushed a commit to Kleidukos/cabal that referenced this issue Mar 30, 2022
andreabedini pushed a commit to andreabedini/cabal that referenced this issue May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants