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.

Sign up for GitHub

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

Jump to bottom

exceptions 0.10 #3615

Closed
16 of 25 tasks
DanBurton opened this issue May 11, 2018 · 20 comments
Closed
16 of 25 tasks

exceptions 0.10 #3615

DanBurton opened this issue May 11, 2018 · 20 comments
Labels
failure: bounds

Comments

@DanBurton
Copy link
Contributor

DanBurton commented May 11, 2018 •
edited by juhp
Loading

Most of you should have already been notified of this, but I'm opening a new issue to clarify what's going on. We will maintain the constraint of exceptions < 0.9 until a few more packages have upgraded to compatibility with exceptions-0.10.

exceptions-0.10.0 (Edward Kmett ekmett@gmail.com @ekmett) is out of bounds for:

The above may be removed from the stackage nightly build plan in the near future in order to allow exceptions-0.10.* into the build plan. If that does happen, then the following, which have exceptions as a transitive dependency, may also be removed:

hailgun (not present) depended on by:

hslua (not present) depended on by:

network-simple (not present) depended on by:

transformers-either (not present) depended on by:

pandoc (not present) depended on by:

  • hakyll-4.12.2.0 (>=2.0.5 && < 2.3). Jasper Van der Jeugt @jaspervdj. @jaspervdj. Used by: library, executable
  • pandoc-citeproc-0.14.3.1 (>=1.16 && < 2.3). John MacFarlane jgm@berkeley.edu @jgm. @jgm. Used by: library, executable, test-suite
@DanBurton DanBurton mentioned this issue May 11, 2018
Closed
68 tasks
@thumphries thumphries mentioned this issue May 11, 2018
Open
@lambdageek lambdageek mentioned this issue May 11, 2018
Merged
@barrucadu
Copy link
Contributor

Fixed in irc-client-1.1.0.3

@lambdageek
Copy link
Contributor

Fixed in unbound-generics-0.3.3

@parsonsmatt
Copy link
Contributor

Fixed in monad-logger-prefix-0.1.10

@jwiegley
Copy link
Contributor

Fixed in hierarchy-1.0.2

@CristhianMotoche
Copy link
Contributor

Fixed in dotenv-0.5.2.5

@tarleb
Copy link
Contributor

tarleb commented May 11, 2018

Fixed in hslua-0.9.5.2

@CristhianMotoche
Copy link
Contributor

Fixed in inflections-0.4.0.3

@hverr
Copy link
Contributor

hverr commented May 13, 2018

Fixed in haskey-0.3.0.2 and haskey-mtl-0.3.0.1

DanBurton added a commit that referenced this issue May 13, 2018
@DanBurton
Unconstrain exceptions, block various, see #3615
c975097
@DanBurton
Copy link
Contributor Author

The following were removed from the Stackage nightly build plan, for the following reasons:

exceptions-0.10.0 is out of bounds for:

hailgun (not present) depended on by:

network-simple (not present) depended on by:

transformers-either (not present) depended on by:

@DanBurton DanBurton mentioned this issue May 13, 2018
Merged
3 tasks
@awalterschulze
Copy link
Contributor

May I ask what is the preferred package to use that contains EitherT ?
Or is this a deprecated style of haskell programming?

@parsonsmatt
Copy link
Contributor

transformers defines ExceptT in Control.Monad.Trans.Except. The EitherT name lost out to ExceptT.

@DanBurton
Copy link
Contributor Author

@awalterschulze I believe ExceptT from Control.Monad.Trans.Except (transformers) would be preferred.

@awalterschulze
Copy link
Contributor

ha ha funny, that is what I started with :D
Good to know. I'll bring my library back up to date.

@awalterschulze
Copy link
Contributor

Fixed in katydid-0.3.1.0

@k0001
Copy link
Contributor

k0001 commented May 15, 2018 via email

@ekmett
Copy link
Contributor

ekmett commented May 15, 2018 •
edited
Loading

@awalterschulze:

I wrote EitherT first, in the either package. Then it was copied into transformers, at which time the bikeshed got recolored to ExceptT.

I maintained the older EitherT code long enough that ExceptT fell into almost every reasonable support window, and along the way I wrote transformers-compat to even further provide a wider support window fallback so that ExceptT (and other newer transformers features) were available clear back into GHC 7.2 territory.

At that point, having a separately maintained EitherT was just adding division to the community so I let it die in favor of having one home for the class, despite not personally liking the new name all that much.

At the risk of putting words in other people's mouths, and stating third-party positions incorrectly, transformers-either seems to be an attempt to resurrect the EitherT name, as some folks feel more strongly about that color of the bikeshed and impact on their existing code from making the move than the duplication / split issue.

@MichelBoucey
Copy link
Contributor

Fixed in cayley-client-0.4.6

@awalterschulze
Copy link
Contributor

awalterschulze commented May 16, 2018 •
edited
Loading

@ekmett Not a problem at all Edward.
I am all for standardizing errors/exceptions in Haskell, even if that means sacrificing the way I was reporting errors.
As long as I can be explicit and attempt to be total about the fact that I am possibly returning errors.
Thanks so much for all your work.

@tmcgilchrist
Copy link
Contributor

Fixed in transformers-either-0.1.1

@akru
Copy link
Contributor

akru commented May 22, 2018

Fixed in web3-0.7.3.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
failure: bounds
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests