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:
Fixed in irc-client-1.1.0.3
Fixed in unbound-generics-0.3.3
Fixed in monad-logger-prefix-0.1.10
Fixed in hierarchy-1.0.2
Fixed in dotenv-0.5.2.5
Fixed in hslua-0.9.5.2
Fixed in inflections-0.4.0.3
Fixed in haskey-0.3.0.2 and haskey-mtl-0.3.0.1
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:
May I ask what is the preferred package to use that contains EitherT ?
Or is this a deprecated style of haskell programming?
transformers defines ExceptT in Control.Monad.Trans.Except. The EitherT name lost out to ExceptT.
@awalterschulze I believe ExceptT from Control.Monad.Trans.Except (transformers) would be preferred.
ha ha funny, that is what I started with :D
Good to know. I'll bring my library back up to date.
Fixed in katydid-0.3.1.0
Fixed in network-simple-0.4.1
On Tue, May 15, 2018, 14:43 Walter Schulze notifications@github.com wrote:
Fixed in katydid-0.3.1.0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fpco/stackage/issues/3615#issuecomment-389152696, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAM5lOQk6DWgdDhUjGQBknQHxFv62Ocks5tys1igaJpZM4T6xGt
.
@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.
Fixed in cayley-client-0.4.6
@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.
Fixed in transformers-either-0.1.1
Fixed in web3-0.7.3.0
Most helpful comment
@awalterschulze:
I wrote
EitherTfirst, in theeitherpackage. Then it was copied intotransformers, at which time the bikeshed got recolored toExceptT.I maintained the older
EitherTcode long enough thatExceptTfell into almost every reasonable support window, and along the way I wrotetransformers-compatto even further provide a wider support window fallback so thatExceptT(and other newertransformersfeatures) were available clear back into GHC 7.2 territory.At that point, having a separately maintained
EitherTwas 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-eitherseems to be an attempt to resurrect theEitherTname, 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.