Skip to content

Stop if cannot attain requested index-state, #8076. #8077

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

philderbeast
Copy link
Collaborator

As this is a change of behaviour, we will need a changelog entry won't we?

I intend to supplement this by changing "this command" with the actual command name.

The rendered output:

> cabal build --enable-tests
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.

@Mikolaj Mikolaj linked an issue Apr 2, 2022 that may be closed by this pull request
@Mikolaj
Copy link
Member

Mikolaj commented Apr 2, 2022

Yes, a tiny changelog file and a test would be necessary. Let me also repeat the questions about how breaking change this is and how can be mitigate the breakage, hoping that others would join the discussion:

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?

Edit: the question was answered in the issue ticket. Some mitigation, though, e.g., an instruction how to get the old behaviour, would be great.

@gbaz
Copy link
Collaborator

gbaz commented Apr 7, 2022

We discussed this at the cabal advisors meeting and think this makes sense. Just needs a changelog and then we can merge.

Copy link
Member

@jneira jneira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After the further issue discussion i am for throwing the error, but i would ask to suggest --index-state=HEAD as the more direct way to override the requested index state and ignore it.
Also maybe we should wait for #8086 or make the message taking in account.

then die' verbosity $
"Stopping this command as the requested index-state=" ++ prettyShow ts0
++ " is newer than (" ++ prettyShow (isiMaxTime isi)
++ "), the most recent state of '" ++ unRepoName rname
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

taking in account #8086 maybe we could change it with something like:

Suggested change
++ "), the most recent state of '" ++ unRepoName rname
++ "), the local state of '" ++ unRepoName rname

maybe HEAD instead of local? maybe it would be less clear for newcomers

"Stopping this command as the requested index-state=" ++ prettyShow ts0
++ " is newer than (" ++ prettyShow (isiMaxTime isi)
++ "), the most recent state of '" ++ unRepoName rname
++ "'. You could try 'cabal update' to bring down a later state or request an earlier timestamp for index-state."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
++ "'. You could try 'cabal update' to bring down a later state or request an earlier timestamp for index-state."
++ "'. You could try 'cabal update' to bring down a later state or force the use of current local state with `--index-state=HEAD`."

you have to use a index-sate <= HEAD and it seems to me than is more frequent use HEAD than a older one

@philderbeast philderbeast force-pushed the fix/index-state-fallback-8076 branch from 92ef1cf to b995ca2 Compare May 16, 2022 21:03
Copy link
Member

@Mikolaj Mikolaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for the PR. I'm entering this early review to block this on changelog, on some mitigations/warnings about the breaking change (e.g., some ideas from #8076 (comment)) and, ideally, a test.

@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Sep 1, 2022
@ulysses4ever ulysses4ever removed the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Sep 3, 2022
@ulysses4ever
Copy link
Collaborator

@philderbeast are you interested in finishing this off? That’d be super cool!

@philderbeast
Copy link
Collaborator Author

Yes I would like to finish this.

@Kleidukos
Copy link
Member

Marking this PR as draft for now 🙂

@Kleidukos Kleidukos marked this pull request as draft May 17, 2023 06:39
@andreabedini
Copy link
Collaborator

#8944 is a more recent take on the same problem.
@philderbeast I suggest you leave a comment there if you believe that PR is missing anything you had done here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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