package ppx_expect

  1. Overview
  2. Docs
Cram like framework for OCaml

Install

Dune Dependency

Authors

Maintainers

Sources

v0.17.2.tar.gz
md5=055c8c86665d158e0b03494a3e188f1c
sha512=c6394522da7f1e03df5d2f62766aa8534c09a12efff7908cc1215b06959e6eeaa2cb85514cd5def1582db66455ed922024387f28b84b4412aed4879ea905c38a

Description

Part of the Jane Street's PPX rewriters collection.

Published: 14 Oct 2024

README

README.mdx

expect-test - a Cram-like framework for OCaml
=============================================


# Introduction

Expect-test is a framework for writing tests in OCaml, similar to
[Cram](https://bitheap.org/cram/).

Expect-tests mimic the (now less idiomatic)
[inline test](https://github.com/janestreet/ppx_inline_test)
framework in providing a
`let%expect_test` construct.

The body of an expect-test can contain output-generating code, interleaved with
`[%expect]` extension expressions to denote the expected output.

When run, expect-tests pass iff the output [_matches_](#matching-behavior) the expected
output. If a test fails, the `inline_tests_runner` outputs a diff and creates a file with
the suffix ".corrected" containing the actual output.

Here is an example expect-test in `foo.ml`:

<!-- $MDX file=./test/negative-tests/for-mdx/foo.ml,part=addition -->
```ocaml
open! Core

let%expect_test "addition" =
  printf "%d" (1 + 2);
  [%expect {| 4 |}]
;;
```

When the test runs, the `inline_tests_runner` creates `foo.ml.corrected` with contents:

<!-- $MDX file=./test/negative-tests/for-mdx/foo.ml.corrected.expected,part=addition -->
```ocaml
open! Core

let%expect_test "addition" =
  printf "%d" (1 + 2);
  [%expect {| 3 |}]
;;
```

`inline_tests_runner` also outputs:

<!-- $MDX file=./test/negative-tests/for-mdx/test-output.expected -->
```
------ foo.ml
++++++ foo.ml.corrected
File "foo.ml", line 6, characters 0-1:
 |open! Core
 |
 |let%expect_test "addition" =
 |  printf "%d" (1 + 2);
-|  [%expect {| 4 |}]
+|  [%expect {| 3 |}]
 |;;
 |
```

Diffs are shown in color if the `-use-color` flag is passed to the inline test runner
executable.

# Common usage

Each `[%expect]` block matches all the output generated since the previous `[%expect]`
block (or the beginning of the test). In this way, when multiple `[%expect]` blocks are
interleaved with test code, they can help show which part of the test produced which
output.

The following test:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml,part=interleaved -->
```ocaml
let%expect_test "interleaved" =
  let l = [ "a"; "b"; "c" ] in
  printf "A list [l]\n";
  printf "It has length %d\n" (List.length l);
  [%expect {| A list [l] |}];
  List.iter l ~f:print_string;
  [%expect
    {|
    It has length 3
    abc
    |}]
;;
```

is rewritten as

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=interleaved -->
```ocaml
let%expect_test "interleaved" =
  let l = [ "a"; "b"; "c" ] in
  printf "A list [l]\n";
  printf "It has length %d\n" (List.length l);
  [%expect
    {|
    A list [l]
    It has length 3
    |}];
  List.iter l ~f:print_string;
  [%expect {| abc |}]
;;
```

When there is "trailing" output at the end of a `let%expect_test` (output that has yet to
be matched by some `[%expect]` block), a new `[%expect]` block is appended to the test
with the trailing output:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml,part=trailing -->
```ocaml
let%expect_test "trailing output" =
  print_endline "Hello";
  [%expect {| Hello |}];
  print_endline "world"
;;
```

becomes:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=trailing -->
```ocaml
let%expect_test "trailing output" =
  print_endline "Hello";
  [%expect {| Hello |}];
  print_endline "world";
  [%expect {| world |}]
;;
```

# Matching behavior

You might have noticed that the contents of the `[%expect]` blocks are not _exactly_ the
program output; in some of the examples above, they contain a different number of leading
and trailing newlines, and are indented to match the code indentation. We say the contents
of a block `[%expect str]` (where `str` is some string literal) _match_ the output at that
block if the output, after we format it to standardize indentation and other whitespace,
is identical to the contents of `str`
after it has been similarly formatted
.

The formatting applied depends on the type of delimiter used in `str` (i.e. whether it a
`"quoted string"` or a `{xxx| delimited string |xxx}`). To summarize:

* Output containing only whitespace is formatted as `[%expect {| |}]` or `[%expect ""]`.
* Output where only one line contains non-whitespace characters is formatted onto a single
  line, as `[%expect {| output |}]` or `[%expect "output"]`.
* Output where multiple lines contain non-whitespace characters is formatted so that:
  - There is no trailing whitespace on lines with content.
  - The relative indentation of the lines is preserved.
  - In `{| delimited strings |}`, the least-indented line with content (the "left margin"
    of the output) is aligned to be two spaces past the indentation of the `[%expect]`
    block.
  - In `"quoted string"`, the least-indented line is indented by exactly one space (this
    plays the nicest with `ocamlformat`'s existing decisions about how to format string
    literals).
  - There is one empty line before and one empty line after the contents.


Here is an example containing several cases of output that are subject to distinct
formatting rules and how they appear in `[%expect]` and `[%expect_exact]` blocks:

<details>
<summary>Expand examples</summary>

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=matching -->
```ocaml
let%expect_test "matching behavior --- no content" =
  printf "     ";
  [%expect {| |}];
  printf "     ";
  [%expect ""];
  printf "     ";
  [%expect_exact {|     |}];
  printf "     ";
  [%expect_exact "     "]
;;

let%expect_test "matching behavior --- one line of content" =
  printf "\n   This is one line\n\n";
  [%expect {| This is one line |}];
  printf "\n   This is one line\n\n";
  [%expect "This is one line"];
  printf "\n   This is one line\n\n";
  [%expect_exact
    {|
   This is one line

|}];
  printf "\n   This is one line\n\n";
  [%expect_exact "\n   This is one line\n\n"]
;;

let%expect_test "matching behavior --- multiple lines of content" =
  printf
    {|
Once upon a midnight dreary,
  while I pondered, weak and weary,
Over many a quaint and curious
  volume of forgotten lore |};
  [%expect
    {|
    Once upon a midnight dreary,
      while I pondered, weak and weary,
    Over many a quaint and curious
      volume of forgotten lore
    |}];
  printf
    {|
Once upon a midnight dreary,
  while I pondered, weak and weary,
Over many a quaint and curious
  volume of forgotten lore |};
  [%expect
    " \n\
    \ Once upon a midnight dreary,\n\
    \   while I pondered, weak and weary,\n\
    \ Over many a quaint and curious\n\
    \   volume of forgotten lore\n\
    \ "];
  printf
    {|
Once upon a midnight dreary,
  while I pondered, weak and weary,
Over many a quaint and curious
  volume of forgotten lore |};
  [%expect_exact
    {|
Once upon a midnight dreary,
  while I pondered, weak and weary,
Over many a quaint and curious
  volume of forgotten lore |}];
  printf
    {|
Once upon a midnight dreary,
  while I pondered, weak and weary,
Over many a quaint and curious
  volume of forgotten lore |};
  [%expect_exact
    "\n\
     Once upon a midnight dreary,\n\
    \  while I pondered, weak and weary,\n\
     Over many a quaint and curious\n\
    \  volume of forgotten lore "]
;;
```
</details>

Expect-test is by default permissive about this formatting, so that a
`[%expect]` block that is correct modulo formatting is
accepted. However, passing `-expect-test-strict-indentation=true` to
the ppx driver makes the test runner issue corrections for blocks that
do not satisfy the indentation rules.
For example, the following:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml,part=bad-format -->
```ocaml
let%expect_test "bad formatting" =
  printf "a\n    b";
  [%expect
    {|
a
    b |}]
;;
```
is corrected to:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=bad-format -->
```ocaml
let%expect_test "bad formatting" =
  printf "a\n    b";
  [%expect
    {|
    a
        b
    |}]
;;
```

(to add the required indentation and trailing newline)


# Reachability

## Expects reached from multiple places

A `[%expect]` extension can be encountered multiple times if it is in e.g. a functor or a
function:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml,part=function -->
```ocaml
let%expect_test "function" =
  let f output =
    print_string output;
    [%expect {| hello world |}]
  in
  f "hello world";
  f "hello world"
;;
```

The test passes if the `[%expect]` block matches the output each time it is encountered,
as described in the section on [matching behavior](#matching-behavior).

If the outputs are not consistent, then the corrected file contains a report of all of the
outputs that were captured, in the order that they were captured at runtime.

For example, calling `f` in the snippet above with inconsistent arguments will produce:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=broken-function -->
```ocaml
let%expect_test "function" =
  let f output =
    print_string output;
    [%expect
      {|
      (* expect_test: Test ran multiple times with different test outputs *)
      ============================ Output 1 / 4 ============================
      hello world
      ============================ Output 2 / 4 ============================
      goodbye world
      ============================ Output 3 / 4 ============================
      once upon
      a midnight dreary
      ============================ Output 4 / 4 ============================
      hello world
      |}]
  in
  f "hello world";
  f "goodbye world";
  f "once upon\na midnight dreary";
  f "hello world"
;;
```


## Unreached expects

Every `[%expect]` and `[%expect_exact]` block in a `let%expect_test` must be reached at
least once if that test is ever run. Failure for control flow to reach a block is _not_
treated like recording empty output at a block. The extension expression
`[%expect.unreachable]` is used to indicate that some part of an expect test shouldn't be
reached; if control flow reaches that point anyway, the corrected file replaces the
`[%expect.unreachable]` with a plain old expect containing the output collected until that
point. Conversely, if control flow never reaches some `[%expect]` block, that block is
turned into a `[%expect.unreachable]`. For example:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml,part=unreachable -->
```ocaml
let%expect_test "unreachable" =
  let interesting_bool = 3 > 5 in
  printf "%b\n" interesting_bool;
  if interesting_bool
  then [%expect {| true |}]
  else (
    printf "don't reach\n";
    [%expect.unreachable])
;;
```
becomes:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=unreachable -->
```ocaml
let%expect_test "unreachable" =
  let interesting_bool = 3 > 5 in
  printf "%b\n" interesting_bool;
  if interesting_bool
  then [%expect.unreachable]
  else (
    printf "don't reach\n";
    [%expect
      {|
      false
      don't reach
      |}])
;;
```

Note that, for an expect block that is sometimes reachable and sometimes not, that block
passes if the output captured at that block matches every time the block is encountered.
For example, the following test passes:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=sometimes-reachable -->
```ocaml
module Test (B : sig
    val interesting_opt : int option
  end) =
struct
  let%expect_test "sometimes reachable" =
    match B.interesting_opt with
    | Some x ->
      printf "%d\n" x;
      [%expect {| 5 |}]
    | None -> [%expect {| |}]
  ;;
end

module _ = Test (struct
    let interesting_opt = Some 5
  end)

module _ = Test (struct
    let interesting_opt = None
  end)

module _ = Test (struct
    let interesting_opt = Some 5
  end)
```

# Exceptions

When an exception is raised by the body of an expect-test, the `inline_test_runner` shows
it (and, if relevant, any output generated by the test that had not yet been captured) in
a `[@@expect.uncaught_exn]` attribute attached to the corresponding `let%expect_test`.
`[%expect]` blocks in the test are treated according to the usual rules: those reached
before the exception is raised capture output as usual, and those that "would have" been
reached after are marked as unreachable:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml,part=exn -->
```ocaml
let%expect_test "exception" =
  Printexc.record_backtrace false;
  printf "start!";
  [%expect {| |}];
  let sum = 2 + 2 in
  if sum <> 3
  then (
    printf "%d" sum;
    failwith "nope");
  printf "done!";
  [%expect {| done! |}]
;;
```

becomes:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=exn -->
```ocaml
let%expect_test "exception" =
  Printexc.record_backtrace false;
  printf "start!";
  [%expect {| start! |}];
  let sum = 2 + 2 in
  if sum <> 3
  then (
    printf "%d" sum;
    failwith "nope");
  printf "done!";
  [%expect.unreachable]
[@@expect.uncaught_exn
  {|
  (Failure nope)
  Trailing output
  ---------------
  4
  |}]
;;
```

Unlike `[%expect]` blocks, which might be reached on some runs of a test and not others, a
test with an `[@@expect.uncaught_exn]` attribute _must_ raise every time it is run.
Changing the `None` branch of the functorized test from [before](#unreached-expects) to
raise gives:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=sometimes-raises -->
```ocaml
module Test' (B : sig
    val interesting_opt : int option
  end) =
struct
  let%expect_test "sometimes raises" =
    match B.interesting_opt with
    | Some x ->
      printf "%d\n" x;
      [%expect {| 5 |}]
    | None -> failwith "got none!"
  [@@expect.uncaught_exn
    {|
    (* expect_test: Test ran multiple times with different uncaught exceptions *)
    =============================== Output 1 / 3 ================================
    <expect test ran without uncaught exception>
    =============================== Output 2 / 3 ================================
    (Failure "got none!")
    =============================== Output 3 / 3 ================================
    <expect test ran without uncaught exception>
    |}]
  ;;
end

module _ = Test' (struct
    let interesting_opt = Some 5
  end)

module _ = Test' (struct
    let interesting_opt = None
  end)

module _ = Test' (struct
    let interesting_opt = Some 5
  end)
```


# Output capture

The extension point `[%expect.output]` evaluates to a `string` with the output that would
have been captured had an `[%expect]` node been there instead.

One idiom for testing non-deterministic output is to capture the output using
`[%expect.output]` and post-process it:

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=output-capture -->
```ocaml
(* Suppose we want to test code that attaches a timestamp to everything it prints *)
let print_message s = printf "%s: %s\n" (Time_float.to_string_utc (Time_float.now ())) s

let%expect_test "output capture" =
  (* A simple way to clean up the non-determinism is to 'X' all digits *)
  let censor_digits s = String.map s ~f:(fun c -> if Char.is_digit c then 'X' else c) in
  print_message "Hello";
  [%expect.output] |> censor_digits |> print_endline;
  [%expect {| XXXX-XX-XX XX:XX:XX.XXXXXXZ: Hello |}];
  print_message "world";
  [%expect.output] |> censor_digits |> print_endline;
  [%expect {| XXXX-XX-XX XX:XX:XX.XXXXXXZ: world |}]
;;
```

Other uses of `[%expect.output]` include:

* Sorting lines of output printed in nondeterministic order.
* Passing output that is known to be a sexp to `t_of_sexp` and performing tests on the
  resulting structure.
* Performing some sort of additional validation on the output before printing it to a
  normal `[%expect]` block.

# Configuration

Expect-test exposes hooks for configuring how the bodies of expect tests are run, which
can be used to set up and tear down test environments, sanitize output, or embed
`[%expect]` expressions in a monadic computation, like a `Deferred.t`.

Each `let%expect_test` reads these configurations from the module named
`Expect_test_config` in the scope of that let binding. The default module in scope defines
no-op hooks that the user can override. To do so, first include the existing
`Expect_test_config`, then override a subset of the following interface:

```ocaml
module type Expect_test_config = sig
  (** The type of the expression on the RHS of a [let%expect_test]
      binding is [unit IO.t] *)
  module IO : sig
      type 'a t

      val return : 'a -> 'a t
  end

  (** Run an IO operation until completion *)
  val run : (unit -> unit IO.t) -> unit

  (** [sanitize] can be used to map all output strings, e.g. for cleansing. *)
  val sanitize : string -> string

  (** This module type actually contains other definitions, but they
      are for internal testing of [ppx_expect] only. *)
end
```

For example, `Async` exports an `Expect_test_config` equivalent to:

```ocaml skip
module Expect_test_config = struct
  include Expect_test_config

  module IO = Async_kernel.Deferred

  let run f = Async_unix.Thread_safe.block_on_async_exn f
end
```

If we want to consistently apply the same sanitization to all of the output in our expect
test, like we did in the timestamp example above, we can override
`Expect_test_config.sanitize`. This cleans up the testing code and removes the need to use
`[%expect.output]`.

<!-- $MDX file=./test/negative-tests/for-mdx/mdx_cases.ml.corrected.expected,part=sanitization -->
```ocaml
(* Suppose we want to test code that attaches a timestamp to everything it prints *)
let print_message s = printf "%s: %s\n" (Time_float.to_string_utc (Time_float.now ())) s

module Expect_test_config = struct
  include Expect_test_config

  (* A simple way to clean up the non-determinism is to 'X' all digits *)
  let sanitize s = String.map s ~f:(fun c -> if Char.is_digit c then 'X' else c)
end

let%expect_test "sanitization" =
  print_message "Hello";
  [%expect {| XXXX-XX-XX XX:XX:XX.XXXXXXZ: Hello |}];
  print_message "world";
  [%expect {| XXXX-XX-XX XX:XX:XX.XXXXXXZ: world |}]
;;
```

# Build system integration

Follow the same rules as for
[ppx_inline_test](https://github.com/janestreet/ppx_inline_test?tab=readme-ov-file#building-and-running-the-tests-outside-of-jane-street-with-dune).

Dependencies (7)

  1. ppxlib >= "0.28.0"
  2. dune >= "3.11.0"
  3. stdio >= "v0.17" & < "v0.18"
  4. ppx_inline_test >= "v0.17" & < "v0.18"
  5. ppx_here >= "v0.17" & < "v0.18"
  6. base >= "v0.17" & < "v0.18"
  7. ocaml >= "5.1.0"

Dev Dependencies

None

  1. ansi-parse >= "0.4.0"
  2. api-watch
  3. arrayjit
  4. autofonce
  5. autofonce_config
  6. autofonce_core
  7. autofonce_lib
  8. autofonce_m4
  9. autofonce_misc
  10. autofonce_patch
  11. autofonce_share
  12. bio_io >= "0.2.1"
  13. bitpack_serializer
  14. bitwuzla
  15. bitwuzla-c
  16. bitwuzla-cxx
  17. camelot >= "1.3.0"
  18. charInfo_width
  19. combinaml
  20. combinat < "3.0"
  21. ctypes_stubs_js
  22. cudajit
  23. dap
  24. data-encoding >= "0.6"
  25. dkml-install-runner < "0.5.3"
  26. dream
  27. dream-pure
  28. drom
  29. drom_lib
  30. drom_toml
  31. dune-action-plugin
  32. electrod >= "0.1.6" & < "0.2.1"
  33. ez_cmdliner >= "0.2.0"
  34. ez_config >= "0.2.0"
  35. ez_file >= "0.2.0"
  36. ez_hash < "0.5.3"
  37. ez_opam_file
  38. ez_search
  39. ez_subst
  40. feather >= "0.2.0"
  41. fiat-p256 < "0.2.0"
  42. GT >= "0.4.0" & < "0.5.0"
  43. gccjit
  44. graphv
  45. graphv_core
  46. graphv_core_lib
  47. graphv_font
  48. graphv_font_js
  49. graphv_font_stb_truetype
  50. graphv_gles2
  51. graphv_gles2_native
  52. graphv_gles2_native_impl
  53. graphv_webgl
  54. graphv_webgl_impl
  55. header-check
  56. hl_yaml
  57. http-cookie >= "4.0.0"
  58. http-multipart-formdata >= "2.0.0"
  59. hyper
  60. imguiml
  61. influxdb >= "0.2.0"
  62. js_of_ocaml >= "3.10.0"
  63. js_of_ocaml-compiler >= "3.4.0"
  64. js_of_ocaml-lwt >= "3.10.0"
  65. js_of_ocaml-ocamlbuild >= "3.10.0" & < "5.0"
  66. js_of_ocaml-ppx >= "3.10.0"
  67. js_of_ocaml-ppx_deriving_json >= "3.10.0"
  68. js_of_ocaml-toplevel >= "3.10.0"
  69. js_of_ocaml-tyxml >= "3.10.0"
  70. kdl
  71. knights_tour
  72. kqueue >= "0.2.0"
  73. learn-ocaml >= "0.16.0"
  74. learn-ocaml-client >= "0.16.0"
  75. libbpf
  76. little_logger
  77. loga >= "0.0.5"
  78. lsp < "1.8.0" | >= "1.11.3" & < "1.19.0"
  79. m_tree
  80. merge-fmt >= "0.3"
  81. mlt_parser >= "v0.17.0"
  82. module-graph
  83. neural_nets_lib
  84. nloge
  85. nsq >= "0.4.0" & < "0.5.2"
  86. OCanren-ppx >= "0.3.0~alpha1"
  87. ocaml-lsp-server >= "1.15.0-4.14" & != "1.19.0"
  88. ocaml-protoc-plugin >= "5.0.0"
  89. ocluster >= "0.2"
  90. ocp-search
  91. ocplib_stuff >= "0.3.0"
  92. octez-libs
  93. octez-protocol-009-PsFLoren-libs
  94. octez-protocol-010-PtGRANAD-libs
  95. octez-protocol-011-PtHangz2-libs
  96. octez-protocol-012-Psithaca-libs
  97. octez-protocol-013-PtJakart-libs
  98. octez-protocol-014-PtKathma-libs
  99. octez-protocol-015-PtLimaPt-libs
  100. octez-protocol-016-PtMumbai-libs
  101. octez-protocol-017-PtNairob-libs
  102. octez-protocol-018-Proxford-libs
  103. octez-protocol-019-PtParisB-libs
  104. octez-protocol-020-PsParisC-libs
  105. octez-protocol-alpha-libs
  106. octez-shell-libs
  107. odate >= "0.6"
  108. odoc >= "2.0.0"
  109. odoc-parser
  110. omd >= "2.0.0~alpha3"
  111. opam-bin >= "0.9.5"
  112. opam-check-npm-deps
  113. opam_bin_lib >= "0.9.5"
  114. owork
  115. passage
  116. poll
  117. pp
  118. ppx_deriving_jsonschema >= "0.0.2"
  119. ppx_jane >= "v0.17.0"
  120. ppx_log >= "v0.17.0"
  121. ppx_minidebug
  122. ppx_protocol_conv_json >= "5.0.0"
  123. ppx_quick_test
  124. ppx_relit >= "0.2.0"
  125. ppx_ts
  126. psmt2-frontend >= "0.3.0"
  127. pvec
  128. pyml_bindgen
  129. res_tailwindcss
  130. routes >= "2.0.0"
  131. safemoney >= "0.2.0"
  132. sedlex >= "3.1"
  133. seqes < "0.2"
  134. solidity-alcotest
  135. solidity-common
  136. solidity-parser
  137. solidity-test
  138. solidity-typechecker
  139. spawn < "v0.9.0" | >= "v0.14.0"
  140. tdigest >= "2.2.0"
  141. tezos-benchmark
  142. tezos-client-009-PsFLoren >= "14.0"
  143. tezos-client-010-PtGRANAD >= "14.0"
  144. tezos-client-011-PtHangz2 >= "14.0"
  145. tezos-client-012-Psithaca >= "14.0"
  146. tezos-client-013-PtJakart >= "14.0"
  147. tezos-client-014-PtKathma
  148. tezos-client-015-PtLimaPt
  149. tezos-client-016-PtMumbai
  150. tezos-client-017-PtNairob
  151. tezos-client-alpha >= "14.0"
  152. tezos-injector-013-PtJakart
  153. tezos-injector-014-PtKathma
  154. tezos-injector-015-PtLimaPt
  155. tezos-injector-016-PtMumbai
  156. tezos-injector-alpha
  157. tezos-layer2-utils-016-PtMumbai
  158. tezos-layer2-utils-017-PtNairob
  159. tezos-micheline >= "14.0"
  160. tezos-shell >= "15.0"
  161. tezos-smart-rollup-016-PtMumbai
  162. tezos-smart-rollup-017-PtNairob
  163. tezos-smart-rollup-alpha
  164. tezos-smart-rollup-layer2-016-PtMumbai
  165. tezos-smart-rollup-layer2-017-PtNairob
  166. tezos-stdlib >= "14.0"
  167. tezos-tx-rollup-013-PtJakart
  168. tezos-tx-rollup-014-PtKathma
  169. tezos-tx-rollup-015-PtLimaPt
  170. tezos-tx-rollup-alpha
  171. toplevel_expect_test >= "v0.17.0"
  172. torch < "v0.16.0"
  173. travesty >= "0.3.0" & < "0.6.0" | >= "0.7.0"
  174. um-abt
  175. wtr >= "2.0.0"
  176. wtr-ppx
  177. yocaml >= "2.0.0"
  178. yocaml_cmarkit
  179. yocaml_eio
  180. yocaml_git >= "2.0.0"
  181. yocaml_jingoo >= "2.0.0"
  182. yocaml_mustache >= "2.0.0"
  183. yocaml_omd
  184. yocaml_otoml
  185. yocaml_runtime
  186. yocaml_syndication >= "2.0.0"
  187. yocaml_unix >= "2.0.0"
  188. yocaml_yaml >= "2.0.0"
  189. zanuda

Conflicts (1)

  1. js_of_ocaml-compiler < "5.8"
OCaml

Innovation. Community. Security.