Improve cabal update message

[andreabedini]

This change tries to address #9039 and similar issues.

• cabal update now mentions a "global index-state".
• cabal update reports the head timestamp of the package index as well as the set index-state.

Example:

$ cabal update repository.localhost,2016-09-24T17:47:48Z
Downloading the latest package list from repository.localhost
Package list of repository.localhost is up to date to 2023-12-15T04:30:20Z.
The global index-state for repository.localhost now resolves to 2016-09-24T17:47:48Z.
To revert to previous state run:
    cabal v2-update 'repository.localhost,2022-01-28T02:36:41Z'

$ cabal update repository.localhost,2022-01-28T02:36:41Z
Downloading the latest package list from repository.localhost
Package list of repository.localhost is up to date to 2023-12-15T04:30:20Z.
The global index-state for repository.localhost now resolves to 2022-01-28T02:36:41Z.
To revert to previous state run:
    cabal v2-update 'repository.localhost,2016-09-24T17:47:48Z'

[jasagredo]

I don't really understand the output:

Package list of repository.localhost is up to date at 2023-12-15T04:30:20Z.
The global index-state for repository.localhost now is 2016-09-24T17:47:48Z.

How can it be "up to date" if it refers to a date later than what the global index-state points to?
Or is it the case that you can "download up to the latest" but set the global index to resolve always to a previous date, if not otherwise specified?

[andreabedini]

How can it be "up to date" if it refers to a date later than what the global index-state points to?
Or is it the case that you can "download up to the latest" but set the global index to resolve always to a previous date, if not otherwise specified?

Yes, this is the behaviour I was trying (and failed apparently 😂) to make explicit in the message.

Running cabal update always brings 01-index.tar.gz up to date with the latest available on the repository. 2023-12-15T04:30:20Z is the timestamp of the most recent entry in 01-index.tar.gz. cabal update repository.localhost,2016-09-24T17:47:48Z also brings 01-index.tar.gz up to date but when writes in 01-index.timestamp that the default index state should be 2016-09-24T17:47:48Z unless something else is specified.

I don't know how to express this any better.

[michaelpj]

Hmm, how about something like:

The repository repository.localhost now has data for index-states up to 2023-12-15T04:30:20Z.
The global index-state for the repository repository.localhost has been set to 2016-09-24T17:47:48Z.

[jasagredo]

The most recent known index-state for the repository ......... has been updated to 2023-12-15T04:30:20Z.
The default index-state timestamp for the repository ......... has been set to 2016-09-24T17:47:48Z.

Or something along those lines?

[andreabedini]

That's why I should not do user facing changes 😂

I am happy with

The most recent known index-state for the repository ...
The default index-state timestamp for the repository ...

Should we say something different if the two timestamps are the same (which happens when you just do cabal update, i.e. the vast majority of cases).

[jasagredo]

Perhaps something like:

The most recent known index-state and the default index-state timestamp for the repository ......... have both been updated to 2023-12-15T04:30:20Z.

I think that is quite clear

[andreabedini]

I have updated the message but the test output is now non-reproducible as it contains a variable timestamp. I might need the same workaraound as RejectFutureIndexState.

The thing is that we disabled those two tests anyway (#9593). Maybe it's better to focus on #9540 before this PR.

[ulysses4ever]

I never looked into the "marked output" shenanigans, but they could help to ignore the variable potion of the output?

[gbaz]

This is marked as needs review, but it looks like there's some outstanding test tweaks before it can be reviewed and merged?