Skip to content
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

Relax strict Hackage revision matching? #3520

Closed
snoyberg opened this issue Oct 27, 2017 · 7 comments
Closed

Relax strict Hackage revision matching? #3520

snoyberg opened this issue Oct 27, 2017 · 7 comments

Comments

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Oct 27, 2017

I've seen a few different people report the same "not actually a bug" in the Stack prerelease (or from Arch users using a master-based build). The case is:

  • They've got a custom package-index set up
  • That package index is pointing at a 00-index.tar.gz file (which doesn't keep all revisions) instead of 01-index.tar.gz
  • The new Stack release is stricter about matching revisions listed in a snapshot, erroring out
  • As a result, stack build et al suddenly stop working with the new Stack release

There's a strong argument in favor of keeping this behavior: it provides for proper reproducibility, and usage of 00-index.tar.gz should basically be considered unsupported. On the other hand, revisions are unlikely to break snapshots (though it happens), and therefore we may be able to get away with sweeping this under the rug.

I see a few different options for this next release:

  • Keep the behavior as-is, and tell users that they have a bug
  • Change the behavior back to just warning on a revision mismatch
  • Make a new option to change the behavior on revision mismatch
  • Possibly unrelated: give a warning (that can be silenced via config) when you point at a package index named 00-index.tar.gz

I'm mostly leaning towards no changes, but wanted to open the discussion.

@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Oct 27, 2017

Possibly unrelated: give a warning (that can be silenced via config) when you point at a package index named 00-index.tar.gz

I like this option + keeping current behavior. Though, it does mean adding a new config option.. eh, seems fine.

Loading

@NorfairKing
Copy link
Contributor

@NorfairKing NorfairKing commented Oct 27, 2017

I prefer the Make a new option to change the behavior on revision mismatch option. Compromising reproducability for everyone by default does not sound like a good idea.

Loading

@ruuda
Copy link
Contributor

@ruuda ruuda commented Oct 27, 2017

Looks like this is what I am seeing in commercialhaskell/lts-haskell#74. I am happy that Stack is stricter and builds become more reproducible; the issue is one of documentation. I was not aware of the distinction between 00-index.tar.gz and 01-index.tar.gz. Simply documenting that in a visible place might be sufficient.

Loading

@snoyberg
Copy link
Contributor Author

@snoyberg snoyberg commented Nov 1, 2017

@ruuda I've pushed a commit with a clarification about the two files here:

cbf7986

If you have ideas for improvements there, please send a PR to update the text.

Loading

@snoyberg
Copy link
Contributor Author

@snoyberg snoyberg commented Nov 1, 2017

Alrighty, PR created for the rest of this:

#3541

I've both added a new flag ignore-revision-mismatch, and a simple heuristic to give a nice error message if you're using a 00-index.tar.gz tarball. Hopefully should address all common cases.

Loading

@ruuda
Copy link
Contributor

@ruuda ruuda commented Nov 1, 2017

Looks good to me, thanks for the clarification!

Loading

snoyberg added a commit that referenced this issue Nov 3, 2017
Better errors for 00-index, and ignore-revision-mismatch #3520
@snoyberg
Copy link
Contributor Author

@snoyberg snoyberg commented Nov 3, 2017

Fixed by PR #3541 and cbf7986, closing.

Loading

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

Successfully merging a pull request may close this issue.

None yet
4 participants