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

Add command-line options --hash and --no-hash #390

Merged
merged 2 commits into from
May 14, 2020
Merged

Add command-line options --hash and --no-hash #390

merged 2 commits into from
May 14, 2020

Conversation

sol
Copy link
Owner

@sol sol commented May 2, 2020

This is an alternative proposal for #381. It adds two new command-line flags, --no-hash and --hash. A brief description of the semantics follows.

Conceptually, there are four different modes, of which hpack exposes three to the user.

ForceNoHash

(enabled with --no-hash, implies --force)

  • No hash will be included in the header comment of the generated cabal file

ForceHash

(enabled with --hash, implies --force)

  • A hash will be included in the header comment of the generated cabal file

PreferNoHash

(the default behavior for hpack)

  • When there is no existing cabal file it behaves like ForceNoHash
  • When there is an existing cabal file the convention from that file is followed

PreferHash

(not exposed, but available through the API)

  • When there is no existing cabal file it behaves like ForceHash
  • When there is an existing cabal file the convention from that file is followed

@sol
Copy link
Owner Author

sol commented May 11, 2020

@snoyberg what behavior do you think will be appropriate for stack? Given that the hashes are a pain to work with when you put .cabal under revision control, I'm tempted to remove support for them entirely. Would that work for you?

@snoyberg
Copy link
Contributor

I honestly don't remember the discussion that led to hashes being included in the first place, or what problems the hashes were intended to solve. I can't think of a way this would break Stack, but I may not be remembering a corner case. Do you remember where we discussed this before?

@sol
Copy link
Owner Author

sol commented May 12, 2020

@snoyberg took me a while to dig it up, commercialhaskell/stack#3383 (comment).

@snoyberg
Copy link
Contributor

It looks like the original issue the hashes are meant to solve is: user edits cabal file instead of hpack file. There's a pretty clear warning at the top of the generated cabal file that it's autogenerated, and hpack files are probably better understood now than when that original issue opened. I wouldn't advocate for removing the hash, but I'm also not opposed to it. Entirely your call :)

@snoyberg
Copy link
Contributor

And thanks for doing the digging on finding that, and pinging me on the topic in the first place

@sol sol merged commit f455b78 into master May 14, 2020
@sol sol deleted the add-no-hash branch May 14, 2020 15:18
@Javran
Copy link

Javran commented Dec 5, 2021

For people spending time reading every single line of this PR and yet have no clue how to disable existing hash: just delete your *.cabal file and let it regenerate.

Javran added a commit to Javran/advent-of-code that referenced this pull request Dec 5, 2021
turns out I just need to regenerate this.

"See details in sol/hpack#390" my ass.
@sol
Copy link
Owner Author

sol commented Dec 19, 2021

@Javran this may not be obvious, but hpack --force --no-hash will do what you want.

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.

None yet

3 participants