search

Gabriella439 / Haskell-Pipes-Safe-Library

Safety for the pipes ecosystem
BSD 3-Clause "New" or "Revised" License
26 stars 21 forks source link

Bump for GHC 8.6.1 #37

Closed vmchale closed 6 years ago

vmchale commented 6 years ago

This requires some MonadFail instances, because of a pattern match that might otherwise fail in a do-block.

Gabriella439 commented 6 years ago

@vmchale: It looks like pipes-safe also needs a bump to the containers upper bound to build with GHC 8.6

vmchale commented 6 years ago

Good catch, thanks!

Gabriella439 commented 6 years ago

Sorry for the delay! Thank you for doing this 🙂

vmchale commented 6 years ago

No worries :)

ocharles commented 6 years ago

Is this ready to reach Hackage?

Gabriella439 commented 6 years ago

@ocharles @vmchale: I just uploaded it to Hackage as pipes-safe-2.3.0. I bumped the major version since it introduced a new constraint

acowley commented 6 years ago

Don't we need a MonadFail instance for SafeT m to make this usable? (This is my first exposure to things breaking due to MonadFail, so I may be misunderstanding.) When I update my downstream pipes-safe-using code, I end up with a missing instance for MonadFail (SafeT IO).

Gabriella439 commented 6 years ago

Let me see if I can just get rid of the incomplete pattern match, which would then allow us to remove the MonadFail constraint. If I can do that, then I can blacklist 2.3.0 and instead upload a change to the minor version instead.

Gabriella439 commented 6 years ago

I decided rather than blacklist 2.3.0 to just roll forward with the change and instead add a MonadFail instance like @acowley proposed. I have a pull request up for that here: https://github.com/Gabriel439/Haskell-Pipes-Safe-Library/pull/39

Gabriella439 commented 6 years ago

Alright, master should be fixed. @acowley: Could you verify that the problem is fixed for you on the master branch before I cut a new release?

acowley commented 6 years ago

Everything does build for me now, thank you! This is a somewhat invasive change as every use of a MonadSafe constraint now needs to be paired with a MonadFail constraint for me.

Gabriella439 commented 6 years ago

@acowley: Let me try to also add one more change to remove the MonadFail constraint, then

Gabriella439 commented 6 years ago

@acowley: Alright, try again now. The MonadFail constraint shouldn't be necessary. If that works, I can go back to the original plan of releasing this as pipes-safe-2.2.10 and blacklisting pipes-safe-2.3.0

acowley commented 6 years ago

Everything works without changes to my code now, thank you! That's an interesting change you made to move the pattern match into IO.

Gabriella439 commented 6 years ago

@acowley: Alright, the fix is up on Hackage as pipes-safe-2.3.1. I decided to roll forward with the version number