`cabal build` error, don't warn and fallback to older state.

[philderbeast]

If I have an index-state in the project file that is newer can we please make it an error rather than a warning when cabal build is invoked?

cabal/cabal-install/src/Distribution/Client/IndexUtils.hs

Lines 278 to 283 in ebfd8c7

	if ts0 > isiMaxTime isi
	then warn verbosity $
	"Requested index-state " ++ prettyShow ts0
	++ " is newer than '" ++ unRepoName rname ++ "'!"
	++ " Falling back to older state ("
	++ prettyShow (isiMaxTime isi) ++ ")."

-- cabal.project
packages: .
index-state: 2022-03-22T14:16:26Z

> cabal build all --enable-tests
Warning: Requested index-state 2022-03-22T14:16:26Z is newer than
'hackage.haskell.org'! Falling back to older state (2022-03-14T21:07:44Z).
Resolving dependencies..

We get a warning. It is on us to call cabal update. I'm unhappy that this is a warning and not an error as I don't think it makes sense for cabal build to proceed. Also often there is a lot of build output and it would be easy to miss this warning.

[philderbeast]

If on line 279, I change warn verbosity to error (and add 1000 years to the index-state) then the behaviour is:

> cabal build all --enable-tests
Requested index-state 3022-03-22T14:16:26Z is newer than 'hackage.haskell.org'!
Falling back to older state (2022-03-31T17:42:23Z).
CallStack (from HasCallStack):
  error, called at src/Distribution/Client/IndexUtils.hs:279:26 in
  cbl-nstll-3.7.0.0-e4be6236:Distribution.Client.IndexUtils

[Mikolaj]

I think the codebase uses info, warn, die, die', etc. Raw error may do something different than die, though I don't remember the details.

[Mikolaj]

Anyway, is anybody opposed to this change? Can we think of a workflow it breaks? Should it be an option turned on by a flag somewhere?

[philderbeast]

Here's the behaviour with die' (I changed the message a little):

> cabal build all --enable-tests
Error: cabal: Requested index-state 3022-03-22T14:16:26Z is newer than
'hackage.haskell.org'! Won't optimistically fall back to older state
(2022-03-31T17:42:23Z).

[philderbeast]

@Mikolaj These commands call getSourcePackages: outdated, install, fetch, freeze, get, init, list, info.

If we change the message, could we mention the command? In the example I use "this command" because at getSourcePackages I don't know that the command is cabal build.

> cabal build
Error: cabal: Stopping this command as the requested
index-state=3022-03-22T14:16:26Z is newer than (2022-03-31T17:42:23Z), the
most recent state of 'hackage.haskell.org'. You could try 'cabal update' to
bring down a later state or request an earlier timestamp for index-state.

The same with dieNoWrap instead of die' doesn't have the same prefix of Error: cabal::

> cabal build
Error: Stopping this command as the requested index-state=3022-03-22T14:16:26Z is newer than (2022-03-31T17:42:23Z), the most recent state of 'hackage.haskell.org'. You could try 'cabal update' to bring down a later state or request an earlier timestamp for index-state.

[Mikolaj]

If we change the message, could we mention the command?

IMHO that makes sense.

[philderbeast]

I'd previously spelunked the code finding commands from calling functions. Now I try out the commands and some of them don't get to the fail code path; outdated, build, install, fetch, freeze, get, init, list, info

[jneira]

I really like the new message but i am not sure about making it an error. Maybe you dont want to jump to the new index state: the current one could work and you dont want to invalidate the cache and wait 2 hours to compile dependencies.
But you dont want to change the requested one cause you will use it eventually.
Or maybe you know nothing about the entire thing and you only want to build the package right now, without having to understand what happens and what addtional steps you have to do.

Maybe a little bit convoluted. I know you want to update your hackage index most of times but not sure if always. And make it an error will force you to make some action.

What about mention the possible consequences of not updating the index? It will make the warning larger, more annyoing and users will be eager to silent it :-P

[philderbeast]

@jneira in that case maybe we can add to the message to say that removing the index-state=... requirement will suffice to enable the build command to proceed?

[jneira]

@jneira in that case maybe we can add to the message to say that removing the index-state=... requirement will suffice to enable the build command to proceed?

but keeping it as an error?

then this would hold, no?:

But you dont want to change the requested one cause you will use it eventually.
Or maybe you know nothing about the entire thing and you only want to build the package right now, without having to understand what happens and what addtional steps you have to do.

I am not assuming the requested index state is something the user has set on purpose. It could be part of a given cabal.project from a random project you just want to compile. And maybe you dont want to make changes in the repo files and/or you know nothing about the index state thing.

You could do --index-state=HEAD to override the cabal.project though. Maybe we could suggest that in the error?