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

(https://github.com/haskell/cabal/issues/10483#issuecomment-2456535673 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.)

[geekosaur]

Working on a first cut at this. For now I am requiring that developers either use a system with TH or use cabal.validate.project.local to disable it (example in cabal.release.prroject which explicitly does so). We should find a better way to deal, but so far the answers I am getting are not encouraging.

[ulysses4ever]

I have a different proposal. It's based on the assumption that we have a flag that controls whether we bake in the SHA and, hence, weather we depend on TH or not.

The flag should be off by default because the common case is: you build cabal for local development (perhaps, trying your patch, running some tests with it and so on), and this shouldn't need the SHA and instead would benefit from the faster and more accessible (re: platforms with no TH) process.

Only in the CI we explicitly set the flag on. Now, how exactly we do it (project file or command-line; and weather to rebuild with the flag or build with it from the get-go), we can discuss further if you agree on the proposal above...

[geekosaur]

But I (and I gather Hécate) both use cabal-head builds which we save. I, at least, build from git weekly. Am I CI? Is Hécate?

[ulysses4ever]

You're not, but you're power users who can read the documentation and do the same as what CI does to get the SHA.

[Kleidukos]

Personnally I dogfood the installation of cabal-head from ghcup, so I don't really tweak the build process

[ulysses4ever]

ghcup will take whatever you give it, so that's not relevant. If you need a sha, you can add a flag during build or download the artifact from GitHub. I assumed you did the latter? In that case you're covered because the GitHub artifacts will certainly have the SHA, that's the whole point.

[Kleidukos]

Yeah I'm getting it from GitHub. In any case I'm not too picky on how it's implemented, I just want to support the effort of making it available in our -head releases. :)

[geekosaur]

I was attempting to follow a best practice outside the little Cabal ecosystem.

That said, I am hard put to identify a time where I started to do something and then Artem immediately climbed my frame, and quite frankly I'm tired of it. I give up; it's his problem from now on.

[ulysses4ever]

@geekosaur, I apologize for being overly eager to propose changes and share my view. I've been working on Cabal CI on and off for a couple of years, at least, and I certainly have opinions. It's okay to disagree, and I'm happy to approve alternative designs. Discussing alternatives is what makes the design better.

[geekosaur]

(a) Maybe your first comment would have qualified as that, but your second was actively pushy. (b) It's also the culmination of several months of my spending more time arguing with you than actually doing anything useful.

[Bodigrim]

I'm somewhat confused. I think that unless you compile cabal-install for WASM / JS architectures (which serves absolutely no purpose), TH should be fine. Is there an evidence of contrary? I don't think there is a need in any additional build flags to control this.

[geekosaur]

I believe that is currently true, but not so long ago there wasn't a bytecode linker for ARM so neither ghci nor TH worked. I don't know if the current situation will remain true for any new architectures that might show up in the future, though. (Has a BCO linker been written for RISC-V?)

[Kleidukos]

@supersven got any insight about the RISC-V situation?

[geekosaur]

It's not really that important except as an example of the likely next platform we'll need to deal with. I would be surprised if it turns out to be the last.

[Bodigrim]

I imagine if you want to be fully future proof, you can write

if arch(arm64) || arch(aarch64) -- and a few other arches if any actively used by potential testers
  build-depends:
    githash