Set index-state in generated cabal.config files

[adamgundry]

The cabal.config files generated by stackage-server are useful to replicate a Stackage snapshot using cabal. However currently they say "Due to revisions, this file may not work" and indeed this sometimes happens when package maintainers tighten bounds (e.g. snoyberg/http-client#563 (comment)).

Cabal/Hackage now have a feature to address this, namely index-state. Would it be possible to have the cabal.config file include an index-state with the timestamp of the Hackage index used to build the snapshot? That would avoid the possibility of subsequent revisions breaking the snapshot (although it would mean users have to manually change the index-state to incorporate package updates not present at the time the snapshot was taken).

cc @sol

[sol]

Also, would it make sense to rename the file to cabal.project.freeze (+ redirect for backwards compat), so that you can just do a wget on the URL?

[chreekat]

+1 to both, I myself (re)discovered the /cabal.config endpoint recently and had some of the same thoughts.

(I think there are a lot of things that could be done to make stack/age and cabal/hackage more compatible, and this is one of them)

[DanBurton]

I strongly object.

Stackage snapshots are meant to be a baseline upon which the user can use their own judgment to add more dependencies on top (or update the packages in the snapshot) as needed. Setting the hackage index to the time of the snapshot will lock them out of any packages/versions released after that point, which would prevent most of the useful additions and updates that a user might want to do.

[chreekat]

Thanks Dan, you're totally right. I wonder if, for discoverability, the timestamp used during snapshot citation could still be added to the file *in a comment* that also explains why it is left off by default? I also still wonder if the file/endpoint should be renamed to something other than cabal.config... but then I also wonder if it wouldn't be better designed as a cabal.project file import or something in any case. I think I'd need the input of a cabal expert to answer that.

[philderbeast]

Please don't change the file name from cabal.config. As naming convention, I use *.project only for the project itself and *.config for any other file it imports. Updo follows the same convention and can be configured to import directly from stackage:

import: https://stackage.org/resolver/cabal.config

[philderbeast]

Due to revisions, this file may not work

There's an open issue for adding revisions to Cabal, haskell/cabal#7833. Revisions work well with Stack and I'd like to see Cabal have that feature too.

[chreekat]

haskell/cabal#7833

Browsing that issue, I found arguments against using index-state as a way to pick revisions. I think I agree.

Personally, I'd also like to see Cabal get support for specifying revisions in project configuration. I'd even like Cabal to explore use of Pantry as an alternative method for specifying package locations.