search

haskell / mtl

The Monad Transformer Library
http://www.haskell.org/haskellwiki/Monad_Transformers
Other
362 stars 63 forks source link

Cut a new release of mtl #69

Closed jkachmar closed 2 years ago

jkachmar commented 4 years ago

mtl now provides a number of useful, unreleased changes (among them instances for Control.Monad.Trans.Writer.CPS and Control.Monad.RWS.CPS which were introduced in transformers-0.5.6.2).

Can we get a new release of this library in time for GHC 8.10, or has that ship sailed?

Ailrun commented 4 years ago

Now GHC 8.10 is released. Is there any progress on cutting a new release?

chessai commented 4 years ago

@hvr @RyanGlScott what is the process for cutting a new release of mtl? I'm happy to take over that responsibility but I need to make sure I'm doing everything right.

cartazio commented 4 years ago

last i checked, @ekmett was maintainer, or am i way out of date?

ekmett commented 4 years ago

It is still me. I'd be open to accepting a new maintainer or co-maintainer, @chessai.

chessai commented 4 years ago

@ekmett I'm certainly interested. What is the process for cutting a new release? Are there any tickets we should consider resolving before one?

Ailrun commented 4 years ago

Any updates?

vdukhovni commented 4 years ago

It would sure be nice to see this released, I've just had to jump though some extraneous hoops to wrap RWS.CPS in some code I'm working on, but with this merged I could just write deriving instance MonadRWS and be done...

cartazio commented 4 years ago

Chess has upload perms for hackage now and if more help is needed I’ve asked @Bodigrim to chip in on release engineering , since he has excellent taste!

vdukhovni commented 4 years ago

Good to know this is progressing...

chessai commented 4 years ago

The main issue is that I am not sure what needs to be done (in terms of issues/PRs) before a release, if anything. We could do a release now and work on the other stuff later, or we could work on them now and delay the release. The balance between those two is what has kept me from inaction.

After we have made a decision, we need to take mtl master and build a lot of its biggest reverse dependencies on hackage, and also base/ghc, against it, to make sure we didn't cause mass breakage.

MTL upgrades already thrash binary caches. Avoiding mass breakage is something that needs careful attention. @Bodigrim @cartazio maybe we could do a video call or something to figure out our plan of attack? Anyone else who wants to join in on this? Please let me know.

On Wed, May 13, 2020, 1:51 PM Viktor Dukhovni notifications@github.com wrote:

Good to know this is progressing...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/haskell/mtl/issues/69#issuecomment-628238758, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEOIX2254TFV26J275OE5K3RRMB3PANCNFSM4JYR7B6A .

phadej commented 4 years ago

There is https://hackage.haskell.org/package/writer-cps-mtl-0.1.1.6/docs/Control-Monad-Writer-CPS.html package. And back then when we discussed with @RyanGlScott we decided that it's better to keep writer-cps compat stuff there.

I.e. not to make everything worse by migrating writer-cps-mtl users to mtl. It's PITA.

Remember, mtl is now distributed with GHC. One would like to avoid need for mtl-compat (which exists, but it's not owned by CLC afaik).

phadej commented 4 years ago

The above mentioned discussion is in https://github.com/ekmett/transformers-compat/issues/39

cartazio commented 4 years ago

@phadej do you mean writer-cps-mtl users to mtl-compat. or did you mean mtl?

Ailrun commented 4 years ago

@phadej, do you mean that mtl will never cut a new release? I mean, this repository already contains codes related to Control.Monad.Writer.CPS, so if mtl ever cuts a new release, it will be a part of mtl, do I mistake something?

cartazio commented 4 years ago

I'm reasnoably confident its a typo reference to mtl-compat vs write-csp-mtl being a sibling compat? (does mtl-compat or transformers-compat note this anywhere?).

rather than about mtl

vdukhovni commented 4 years ago

My take is that when it is time to cut the next major release bump of mtl, it should include the (already committed) new instances, and at that point writer-cps-mtl can be updated to just reexport the new mtl module. I would not want to see the orphan implementation in writer-cps-mtl as a long-term solution.

phadej commented 4 years ago

I’m saying that it’s easier to not migrate any new code to mtl as writer-cps-monad already provides the mtl instances for transformers / writer-cps-transformers.

Alternatively one should add CPS transformers to transformers-compat and instances to mtl AND transformers-compat.

Just check how complicated the transformers-compat setup is already:

https://hackage.haskell.org/package/transformers-compat-0.6.5/dependencies

So I ask that if anything is migrated from writer-cps packages to mtl / transformers-compat it’s done in coordinated and double and triple-checked. The coupling between base/transformers/mtl is unfortunate.

Alternatively:

I’d be in favor of removing mtl and text dependency from parsec, (the only thing forcing it them to be boot libs), so both text and mtl don’t need to be shipped with GHC and therefore could be easily reinstallable and left outside of CLC supervision.

Then mtl and text could be improved in its own pace without worries about breaking downstream as GHC won’t force an upgrade.

On 14. May 2020, at 1.09, Junyoung Clare Jang notifications@github.com wrote:

 @phadej, do you mean that mtl will never cut a new release? I mean, this repository already contains codes related to Control.Monad.Writer.CPS, so if mtl ever cuts a new release, it will be a part of mtl, do I mistaken?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

ekmett commented 4 years ago

I'm happy to donate transformers-compat to the CLC if that moves the needle. (I suspect it doesn't, much.)

I have a good deal of sympathy for "migrating is hard" arguments, but I'm not sure we should let that be a barrier to any attempt at further progress. mtl has sat basically unmodified for years, it has to be able to cut a release somehow.

If the data type is in supplied in transformers, and the class is in mtl, then the instance should be in mtl. The current status quo is a rats' nest, requiring the user search flail around blindly searching hackage, and is a needless exception to everything else we supply.

I do believe any work here will need to coordinate with Ryan Scott, for mtl-compat reasons, though.

Bodigrim commented 4 years ago

I’d be in favor of removing mtl and text dependency from parsec, (the only thing forcing it them to be boot libs), so both text and mtl don’t need to be shipped with GHC

@phadej This sounds like a good idea. Do you mean something like this: https://github.com/Bodigrim/parsec/commit/3e122d73dcfac06a3fda07de7e8b93d3e8235e3d?

Kleidukos commented 3 years ago

@Bodigrim @phadej @chessai Where are we standing on that topic?

phadej commented 3 years ago

I'm not the one who can decide about mtl, I just comment on the internet (too much).

Bodigrim commented 3 years ago

Neither am I.

ekmett commented 3 years ago

I'm happy to cede governance of the mtl to the CLC.

emilypi commented 3 years ago

I can cut a release if you add myself and @chessai as maintainers @ekmett

vdukhovni commented 3 years ago

I can cut a release if you add myself and @chessai as maintainers @ekmett

That's probably the easy part. Has a decision been made on the division of responsibilities between:

There seems to be a coordination issue here that cuts across packages, that's the real obstacle...

chessai commented 3 years ago

Are we blocked on #81, which resolved #44?

cartazio commented 3 years ago

I think viktor raises the right point. And I think the division of responsibility should be the one that

A) avoids needlessly breaking preexisting code

B) ensures that future new code need only transformers mtl and mtl/transformers-compat. (Any other compat package should just be a reexport of compat stuff from there )

On Sun, Feb 14, 2021 at 5:12 PM chessai notifications@github.com wrote:

Are we blocked on #81 https://github.com/haskell/mtl/pull/81?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/haskell/mtl/issues/69#issuecomment-778850294, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABBQUTNDQ63RMJLPUSH4TS7BDF3ANCNFSM4JYR7B6A .

vdukhovni commented 3 years ago

FWIW, though it probably does not have to be stated, I don't know enough history, or have broad enough contact with the existing library ecosystem to suggest any particular strategy. I hope that someone with the right expertise will be able to step forward and suggest a specific strategy that can achieve consensus.

phadej commented 3 years ago

I'd suggest the following:

First two packages are maintaiend by Ryan Scott, who is usually very responsive. writer-cps-* packages are maintained by Daniel Mendler who seems to be active on GitHub (nick: @minad).

The current problem is that transformers-compat is a compat package for both transformers and mtl. mtl-compat shims small additional bits.

This is non-trivial engineering task, but relatively straight-forward, though needs careful execution. (causing major versions for transformers-compat and mtl-compat). Especially one needs to make sure that getting duplicate orphans (e.g. from old writer-cps-mtl and new mtl-compat) is at least unluckily, if cannot be avoided completely.

The benefit is that dependency graph would be static. Now it is dynamic, sometimes transformers-compat depends on mtl, sometimes it doesn't.

The follow-up benefit is that evolution of both transformers and mtl won't be hindered by unclear compatibility story.

ekmett commented 3 years ago

added you both to transformers-compat and mtl on hackage

On Mon, Feb 15, 2021 at 12:27 AM Oleg Grenrus notifications@github.com wrote:

I'd suggest the following:

  • make transformers-compat be compat package only for transformers
  • repurpose mtl-compat to be mtl true compat package
  • make writer-cps-transformers use transformers-compat
  • make writer-cps-mtl use mtl-compat

First two packages are maintaiend by Ryan Scott, who is usually very responsive. writer-cps-* packages are maintained by Daniel Mendler who seems to be active on GitHub (nick: @minad https://github.com/minad).

The current problem is that transformers-compat is a compat package for both transformers and mtl. mtl-compat shims small additional bits.

This is non-trivial engineering task, but relatively straight-forward, though needs careful execution. (causing major versions for transformers-compat and mtl-compat).

The benefit is that dependency graph would be static. Now it is dynamic, sometimes transformers-compat depends on mtl sometimes it doesn't.

The follow-up benefit is that evolution of both transformers and mtl won't be hindered by no compatibility story.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/haskell/mtl/issues/69#issuecomment-779047767, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACKMEPRRJLMQTXPELW2ZUTS7DLGXANCNFSM4JYR7B6A .

minad commented 3 years ago

Is someone is interested in maintainer rights for the writer-cps-* compatibility packages? @phadej? This would help in avoiding such coordination issues.

phadej commented 3 years ago

@minad, perfectly would be the same people as for transformers(-compat) and mtl(-compat), i.e. not me.

minad commented 3 years ago

Just to be very explicit, who should be added? I am sorry - I didn't follow the discussion recently. I just got your ping.

Kleidukos commented 3 years ago

Wouldn't that be the whole CLC?

Bodigrim commented 3 years ago

@Kleidukos it is technically impossible. There is no such user group on Hackage.

@minad please grant access to https://hackage.haskell.org/user/chessai and https://hackage.haskell.org/user/topos

minad commented 3 years ago

@emilypi @chessai I added you to the maintainer group on hackage of various writer-cps-* packages. Furthermore I added you to the github repositories https://github.com/minad/writer-cps-transformers and https://github.com/minad/writer-cps-mtl. Please let me know if something else is needed.

chessai commented 3 years ago

@emilypi @chessai I added you to the maintainer group on hackage of various writer-cps-* packages. Furthermore I added you to the github repositories https://github.com/minad/writer-cps-transformers and https://github.com/minad/writer-cps-mtl. Please let me know if something else is needed.

@minad could you please re-send my github invitations? They expired.

Furthermore, Emily and I have committed time coordinating to getting this all done next weekend.

jkachmar commented 2 years ago

Closed via a019ae8247d40fbbe3fc6bef7508cf10b0b6be73 🎉