`cabal --version` on a non-release build should include a Git commit

[geekosaur]

I wonder if cabal --version on a non-release build should include a Git commit. (@geekosaur)

This has been bugging me too, as a daily user of cabal-head, this would be greatly appreciated. (@Kleidukos)

(#10483 (comment) ff.)

[geekosaur]

There's at least one package that provides this information automatically, but I'm not sure we want it as a dependency even if it's restricted to cabal.validate.project.

[geekosaur]

And I'm a daily user of cabal HEAD too, but I do my own (usually weekly) builds of HEAD and 3.12.

[geekosaur]

…the first two I found require TH, so no-go. I may have to cons up my own, although TH is by far the easiest way to do it.

[geekosaur]

The other way to do it is custom Setup for cabal-install, but that bugs me.

[Kleidukos]

There is also the option of reading the data at run-time from a data-file, although now we have to properly install cabal as a package and not just as a lone binary

[Kleidukos]

Relevant Reddit thread https://www.reddit.com/r/haskell/comments/erhwe8/what_is_the_best_way_to_inject_information_into_a/

[ulysses4ever]

There's at least one package that provides this information automatically, but I'm not sure we want it as a dependency

A flag could help to deal with it?

I have been wanting to tackle this issue since day one of cabal-head because the current state is deeply unsatisfactory. We should implement a solution no matter what. And we can always improve the implementation down the road.

[ulysses4ever]

Re data-files: they work great for cabal install but don't work at all with cabal build. Which may cost us another build at CI time. I'd try to avoid all that.

[Kleidukos]

@geekosaur TH being a no-go is a GHC-related limitation? We can control this behaviour with some good old CPP, and only enable this if we're building a -head release, no?

[geekosaur]

It's about platforms that don't have the bytecode backend but do need cabal. (ARM used to fit here, I don't know what currently supported platforms do but there's something somewhere in the tree saying that TH is forbidden in the codebase for this reason.)

[Kleidukos]

I see, thank you.

[ulysses4ever]

Template Haskell is a non-issue if this is hidden behind a flag

[geekosaur]

I wonder if there's a good way to ask if TH is supported without using custom Setup (there's no impl for it and you can't check simply by adding a template-haskell dependency, AFAICT you need ghc --info). (I want to be able to fall back if TH isn't available. Again, I'm not sure simply gating template-haskell on a flag is good enough here, I don't know if we get a stub template-haskell on platforms without a bytecode linker.)

[geekosaur]

I suppose there's also just requiring development to be on platforms with working TH, but I feel like that's poor devx. And requiring a cabal.validate.project.local that flips the flag back off doesn't seem a whole lot better. (cabal.release.project, of course, will force it off, and the default will be false so it will take specific effort for someone building from Hackage to encounter it.)