-
Notifications
You must be signed in to change notification settings - Fork 711
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
Comments
|
We should also think about the backwards compat story for |
Is it documented somewhere which |
Not against this proposal, but wouldn't something like
work too? |
@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" :-) |
okay.jpg |
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?) |
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
+1 to this feature. I also would like to be able to set |
According to the code: And according to the parsing of the script-block: https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/CmdRun.hs#L379 Using the parser for EDIT: the syntax |
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 |
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 Alternate: {- cabal:
executableFields: vals
cabal.project
projectFields: vals
-} Should the header be |
I lean towards I was actually thinking two blocs entirely as in
|
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:
***@***.***>
|
Uh oh!
There was an error while loading. Please reload this page.
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}
andconstraints
shall be supported as exemplified in the example below/cc @typedrat
The text was updated successfully, but these errors were encountered: