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.

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

cohttp-async: base/async v0.16 compatibility #976

Merged
merged 18 commits into from
Jun 27, 2023

Conversation

dkalinichenko-js
Copy link

The next major release of Base will rename the Caml module to Stdlib. The next major release of Async will make the how argument mandatory for certain Deferred operations. This PR updates cohttp-async before releasing these changes, since some Jane Street packages depend on it.

I'm not sure about the testing story for this change. The preview versions of our libraries are accessible at our bleeding edge repo (https://github.com/janestreet/opam-repository), and currently only work with OCaml 4.14.1. We are working towards 5.0.0 compatibility, but do not want it to delay the renaming and API tweaks.

@mseri
Copy link
Collaborator

mseri commented Mar 9, 2023

Thanks. As soon as base/async libraries are released I will test the changes, merge them and make a release. Anybody that uses the dev versions can pin the branch of this PR and use them in the meantime.

@avsm
Copy link
Member

avsm commented Mar 9, 2023

Hang on, I don't think this should be merged until the Base v0.16 release has been cut and submitted. Otherwise, cohttp-async will be uninstallable in the opam-repository, and not suitable for merging there.

@dkalinichenko-js -- what's the rough timeline for v0.16 being publicly released (even as a preview RC?).

@dkalinichenko-js
Copy link
Author

Hang on, I don't think this should be merged until the Base v0.16 release has been cut and submitted. Otherwise, cohttp-async will be uninstallable in the opam-repository, and not suitable for merging there.

@dkalinichenko-js -- what's the rough timeline for v0.16 being publicly released (even as a preview RC?).

Will it actually be uninstallable, or just install the previous version of cohttp-async? I thought it would resolve the dependency to use base v0.15, but maybe I'm wrong.

Rough timeline is late March-early April.

@mseri
Copy link
Collaborator

mseri commented Mar 9, 2023

Hang on, I don't think this should be merged until the Base v0.16 release has been cut and submitted.

That is exactly my suggestion, to leave it open until the upstream release happen

@avsm
Copy link
Member

avsm commented Mar 9, 2023

Sorry @mseri, I entirely misread your message! Quite right.

@d-kalinichenko if this were released onto stable opam-repo, then the cohttp-async package would be uninstallable since there would be no v0.16 base packages (without adding the bleeding edge remote). The easiest way to test the package along with your release is for you to clone the cohttp opam files over to the Jane Street bleeding-edge repository, so they're all included there in a batch.

This is all a little more painful than we would like since you also have to drag along all the other (non-cohttp-async) packages in this repository for the versioning to work out. Easiest just to coordinate with us as you do the v0.16 release and we can release things all at roughly the same time.

dune-project Outdated Show resolved Hide resolved
cohttp-async.opam Outdated Show resolved Hide resolved
@mseri
Copy link
Collaborator

mseri commented Jun 14, 2023

This PR needs more work, not just to fix the CI, but it seems that also some tests need fixing:

File "cohttp-async/test/test_async_integration.ml", lines 83-87, characters 8-56:
83 | ........resps
84 |         |> Deferred.List.iter ~f:(fun (_resp, body) ->
85 |                let expected_body = body_q |> Queue.dequeue_exn in
86 |                body |> Body.to_string >>| fun body ->
87 |                assert_equal ~printer expected_body body)
Error (warning 5 [ignored-partial-application]): this function application is partial,
maybe some arguments are missing.
File "cohttp-async/test/test_async_integration.ml", lines 83-87, characters 8-56:
83 | ........resps
84 |         |> Deferred.List.iter ~f:(fun (_resp, body) ->
85 |                let expected_body = body_q |> Queue.dequeue_exn in
86 |                body |> Body.to_string >>| fun body ->
87 |                assert_equal ~printer expected_body body)
Error: This expression has type
         how:Async_kernel.Monad_sequence.how -> unit io
       but an expression was expected of type 'a io

dune-project Outdated Show resolved Hide resolved
cohttp-curl-async.opam Outdated Show resolved Hide resolved
mseri added a commit to mseri/opam-repository that referenced this pull request Aug 8, 2023
…p-mirage, cohttp-lwt, cohttp-lwt-unix, cohttp-lwt-jsoo, cohttp-eio, cohttp-curl, cohttp-curl-lwt, cohttp-curl-async, cohttp-bench and cohttp-async (6.0.0~alpha2)

CHANGES:

- cohttp-lwt: Do not leak exceptions to `Lwt.async_exception_hook`. (mefyl mirage/ocaml-cohttp#992, mirage/ocaml-cohttp#995)
- http.header, cohttp, cohttp-eio: remove "first" and "move_to_first" and the special treatment of the "host" header (mseri mirage/ocaml-cohttp#988, mirage/ocaml-cohttp#986)
- http.header: introduce "iter_ord" to guarantee iteration following the order of the entries in the headers (mseri mirage/ocaml-cohttp#986)
- do not omit mandatory null Content-Length headers (mefyl mirage/ocaml-cohttp#985)
- cohttp-async, cohttp-curl-async: compatibility with core/async v0.16.0 (mseri, dkalinichenko-js mirage/ocaml-cohttp#976)
- cohttp-lwt server: call conn_closed before drainig the body of response on error (pirbo mirage/ocaml-cohttp#982)
- cohttp-eio: Relax socket interface requirement on `Server.connection_handler`. (mefyl mirage/ocaml-cohttp#983)
mseri added a commit to mseri/opam-repository that referenced this pull request Aug 8, 2023
…p-mirage, cohttp-lwt, cohttp-lwt-unix, cohttp-lwt-jsoo, cohttp-eio, cohttp-curl, cohttp-curl-lwt, cohttp-curl-async and cohttp-async (6.0.0~alpha2)

CHANGES:

- cohttp-lwt: Do not leak exceptions to `Lwt.async_exception_hook`. (mefyl mirage/ocaml-cohttp#992, mirage/ocaml-cohttp#995)
- http.header, cohttp, cohttp-eio: remove "first" and "move_to_first" and the special treatment of the "host" header (mseri mirage/ocaml-cohttp#988, mirage/ocaml-cohttp#986)
- http.header: introduce "iter_ord" to guarantee iteration following the order of the entries in the headers (mseri mirage/ocaml-cohttp#986)
- do not omit mandatory null Content-Length headers (mefyl mirage/ocaml-cohttp#985)
- cohttp-async, cohttp-curl-async: compatibility with core/async v0.16.0 (mseri, dkalinichenko-js mirage/ocaml-cohttp#976)
- cohttp-lwt server: call conn_closed before drainig the body of response on error (pirbo mirage/ocaml-cohttp#982)
- cohttp-eio: Relax socket interface requirement on `Server.connection_handler`. (mefyl mirage/ocaml-cohttp#983)
nberth pushed a commit to nberth/opam-repository that referenced this pull request Jun 18, 2024
…p-mirage, cohttp-lwt, cohttp-lwt-unix, cohttp-lwt-jsoo, cohttp-eio, cohttp-curl, cohttp-curl-lwt, cohttp-curl-async and cohttp-async (6.0.0~alpha2)

CHANGES:

- cohttp-lwt: Do not leak exceptions to `Lwt.async_exception_hook`. (mefyl mirage/ocaml-cohttp#992, mirage/ocaml-cohttp#995)
- http.header, cohttp, cohttp-eio: remove "first" and "move_to_first" and the special treatment of the "host" header (mseri mirage/ocaml-cohttp#988, mirage/ocaml-cohttp#986)
- http.header: introduce "iter_ord" to guarantee iteration following the order of the entries in the headers (mseri mirage/ocaml-cohttp#986)
- do not omit mandatory null Content-Length headers (mefyl mirage/ocaml-cohttp#985)
- cohttp-async, cohttp-curl-async: compatibility with core/async v0.16.0 (mseri, dkalinichenko-js mirage/ocaml-cohttp#976)
- cohttp-lwt server: call conn_closed before drainig the body of response on error (pirbo mirage/ocaml-cohttp#982)
- cohttp-eio: Relax socket interface requirement on `Server.connection_handler`. (mefyl mirage/ocaml-cohttp#983)
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants