Add validation for valid fields in script metadata blocks

[bacchanalia]

The {- cabal: ... -} and {- project: ... -} (with #7997) blocks of a script parse of full the full executable grammar and cabal.project grammar respectively, regardless of whether such fields make sense. Also many fields are broken because using fake-package (see #6977) means that the directory the script project file is relative to is not the same as the directory the script is actually in.

Script specific validation should be added for these blocks.

Executable fields that should warn:

• main-is this will be overridden to be the script
• scope is meaningless for a script, but I don't think it actually breaks anything if set
• install-includes: install is not supported for scripts

Executable fields that don't work as expected with relative paths because of fake-package:

• other-modules
• hs-source-dirs:
• includes:
• include-dirs:
• c-sources:
• cxx-sources:
• asm-sources:
• cmm-sources:
• js-sources:
• extra-lib-dirs:
• extra-framework-dirs:

Project fields that should warn:

• run-tests: scripts can't specify tests
• write-ghc-environment-files: gets put in/is relative to wrong directory because of fake-package

Project fields that don't work as expected with relative paths because of fake-package:

• packages:
• optional-packages:
• extra-prog-path:
• extra-include-dirs:
• extra-lib-dirs:
• extra-framework-dirs:
• remote-repo-cache:
• logs-dir:

[fgaz]

Is source-repository-package supposed to work? I tried and it doesn't have any effect but I think it should if possible

[ulysses4ever]

I'd also like to have source-repository-package working. I recently have been using scripts a lot and I found it very limiting to not being able to use packages not on Hackage (note: I know about local no-index repos but I don't want to got that way). It's funny that not long ago in #8562 I advocated that it's fine to not have access to external cabal.project, but now I badly miss the powers that we lost with that change.

[hellwolf]

It would be great if the project meta data can support package configurations, in order to support non-hackage dependencies including local ones.

(coming from #9084)

[georgefst]

Project fields that don't work as expected with relative paths because of fake-package:

The problem is bigger than that: packages/optional-packages are just completely ignored, even when using absolute paths. It was hypothesised in #8562 (comment) that this "should" work.

While these changes are a step in the right direction, in the short term it's been a big regression that we can no longer sensibly override dependencies. I've honestly considered publishing some of my temporary forks to Hackage because of this, and that's not behaviour we want to encourage!

Is supporting packages and source-repository-package likely to be difficult?

[gbaz]

Is supporting packages and source-repository-package likely to be difficult?

My suspicion is that this is a matter of some flag plumbing, and not a huge conceptual obstacle.

[georgefst]

The problem is bigger than that: packages/optional-packages are just completely ignored, even when using absolute paths. It was hypothesised in #8562 (comment) that this "should" work.

FWIW, passing --project-file is no solution. Cabal complains if the file doesn't exist, but otherwise just seems to ignore any fields in the file.

[hellwolf]

I'd like to have this fixed... at munihac this weekend, anyone in this thread is around?

[bacchanalia]

if anyone is working on this at munihac, my suggestuon is to work on removing the use of fake-package instead of trying to solve this specific issue. See: #6977

[hellwolf]

Fwiw, I found a workaround for now, that is to specify the package-dbs list in the project header.

#!/usr/bin/env -S cabal run thsh --
{- cabal:
build-depends: base, PyF, THSH
default-language: GHC2021
ghc-options: -Wall
-}
{- project:
package-dbs: /home/hellwolf/Projects/my/THSH/dist-newstyle/packagedb/ghc-9.10.1,
             user
-}
{-# LANGUAGE QuasiQuotes #-}

import           THSH

__main__ = [thsh|\
echo hello, world
|]

main = do
  runFuncletWithStdHandles __main__

I will look into cabal code in the future to fix this wart... since it is in the interest of my project to remove such a hack.

[georgefst]

Fwiw, I found a workaround for now, that is to specify the package-dbs list in the project header.

Oof, that's horrible, and I'm probably going to use it.

[hellwolf]

By the way, a correction, the "user" package-db trick didn't work, I had to use the "in place" one directly:

I used the following snippets in my loader of the project:

D=$(readlink -f $(dirname "$0")/..)

COMPILER_ID=$(cabal path --output-format=json | jq -r '.compiler.id')

LOCAL_PACKAGE_DB=$D/dist-newstyle/packagedb/${COMPILER_ID}
USER_PACKAGE_DB=$(cabal path --store-dir)/${COMPILER_ID}-inplace/package.db

I believe you could reuse these to add a wrap to your cabal --package-db for your local project.