Delete Lwt_chan in 4.0.0

[aantron]

Module Lwt_chan is completely superseded by Lwt_io. Lwt_chan has been deprecated (in favor of Lwt_io) since 2009 (fd418dd).

With non-trivial work on the Unix binding potentially coming up, it would be nice not to also have to work on the implementation of the Lwt_chan API, even though most of it forwards to Lwt_io. So, I propose to announce its upcoming removal in the next release (3.1.0), and remove it in release 4.0.0 (autumn 2017).

Following is a list of OPAM packages and/or repos that use Lwt_chan. The recommended course of action for each is to switch to Lwt_io. The linked commit deprecating Lwt_chan refers to different semantics. If this causes concern, refer to Lwt_chan's 60-line implementation over Lwt_io to see if there is any relevant difference, and don't hesitate to discuss and ask questions.

• Eliom uses Lwt_chan in a test @vasilisp
• libres3 @edwintorok
• macaque_lwt @jpdeplaix
• ocsigenserver @vasilisp
• riak @metadave
• socket-daemon @zoggy
• https://github.com/mfp/ocaml-stomp @mfp
• https://github.com/ocsigen/ocsipersist @vasilisp
• https://github.com/ocsigen/ocsimore @vasilisp
• uwt and core-lwt would also be affected by this @fdopen @ivg

EDIT: If one of the OPAM packages isn't being maintained, you (the maintainer!) don't have to do anything. We will put the right upper bounds on lwt in the published opam files when we release 4.0.0.

[bookshelfdave]

👍 I don't plan on/have time to work on any maintenance for the Riak OCaml client.

[aantron]

Also, it seems a lot of PG'OCaml users pass Lwt_chan to a functor @darioteixeira.

@metadave: FYI :) Thanks for taking a look.

[kit-ty-kate]

macaque_lwt is a deprecated library so no work is needed here, I believe.
Except removing the package from opam-repository maybe.

[vasilisp]

@aantron, thanks for the notice. Most of the work for getting rid of Lwt_chan in Ocsigen has already happened in branches. Thumbs up for the removal.

With respect to the PGOcaml functor, here is a straightforward translation to Lwt_io.

[edwintorok]

Go ahead, I don't have any plans for working on libres3 in the near future. When 4.0 is released I can add a constraint in the opam repository if needed. Thanks for the notice.

[Drup]

macaque_lwt is a deprecated library so no work is needed here, I believe.
Except removing the package from opam-repository maybe.

@jpdeplaix What about we don't remove packages that actually work, don't have an equivalent replacement and may have users in some web application (which, by definition, is not in opam) ?
You don't want to work on it anymore, sure, that's your choice. But that's not what "deprecated" means. You can let it around with a version constraints on lwt, and let users port it if needed.

[aantron]

don't have an equivalent replacement

It has several equivalent replacements:

• For ordinary direct use, code I've seen could be replaced in an obvious way with Lwt_io. Can you clarify what is missing from Lwt_io?
• For use when passing to a functor, @vasilisp has provided an example, and we can link people to it (thanks). Among other places, we can include that link in the deprecation message.
• If all else fails, or extra paranoid, one could include the code of Lwt_chan directly into a project, as it's a relatively simple facade over Lwt_io.

The code I found includes several Ocsigen web applications on GitHub. Most of it was either doing simple reading/writing with Lwt_chan, or else instantiating a PG'OCaml functor.

What about we don't remove packages that actually work

Lwt_chan is a module, not a package. I don't want to create a new package in OPAM for a deprecated module, just to put a version constraint on lwt:

• It's pollution of OPAM with a package we don't actually want anyone to use.
• Factoring out a new package is itself a breaking change. If we are going to make one, I propose to delete the module instead.
• If the code I found is representative, the amount of work needed to port from Lwt_chan to Lwt_io is only slightly more than the amount of work to depend on some lwt-lwt_chan.
• Alternatively, to avoid doing any of that work, a user can constrain Lwt to < 4.0.0. That is just as much work as depending on lwt-lwt_chan. And, unless someone wants to maintain Lwt_chan or lwt-lwt_chan, it will have the same effect.
• For packages in OPAM, we can (and routinely do) put the right upper constraints on Lwt ourselves, so downstream maintainers don't have to do anything at all. This is especially useful for packages that aren't seeing maintenance anyway, i.e. for at least @metadave, @jpdeplaix, @edwintorok.

You don't want to work on it anymore, sure, that's your choice.

Indeed, I don't want to work on it. As far as I'm aware, neither does anyone else. It will be at least three months from announcement to 4.0.0. In case of more objections, and especially if someone is willing to work on Lwt_chan in some form, we have that time to change course.

• During this time, those maintaining their software and upgrading Lwt will see warnings on installation of Lwt, and on using Lwt_chan.
• Those not upgrading Lwt hopefully can live with Lwt < 4.0.0 in case they upgrade later, or are willing to port their code at that point.
• Users upgrading after 4.0.0 have a hyperlinked changelog to refer to.

[Drup]

@aantron I was talking about macaque_lwt. I edited my message to make it clearer. My remarks certainly don't apply to your removal process (and as you pointed out, they would be completely wrong). :)

[aantron]

Gah sorry. At least it's good to have all those thoughts written down, since I'll have to write a similar text in the future anyway, as part of the release :)

[aantron]

Also @Drup, even if you may not have intended it, misreading your comment made me think a lot harder about this issue, so thank you :)

[darioteixeira]

Removing Lwt_chan will indeed put a small extra burden on the users of PG'OCaml with Lwt, but IMHO this should not be an obstacle to progress. I'll send a message to the mailing-list with the workaround.