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.