Catala version 1.0.0~beta

[denismerigoux]

Simultaneous release of three packages :

• catala
• catala-lsp
• catala-format

Description of Catala :

Compiler and library for the literate programming language for tax code specification
Catala is a domain-specific language for deriving faithful-by-construction algorithms from legislative texts. See https:// catala-lang.org for more information

---

• Homepage: https://github.com/CatalaLang/catala
• Source repo: git+https://github.com/CatalaLang/catala
• Bug tracker: https://github.com/CatalaLang/catala/issues

---

See #28564 (comment) for the explanation for cataladevmode.

[AltGr]

Going through the reported CI errors:

• lint check: this is not a conf package, but we do use a depext field for groff which has no conf package (this is only used to generate static HTML manpages when compiled with with-doc)
• all lower-bounds check fail because of the older conf-gmp package which is pulled by zarith ; this was already the case in the previous release and is unrelated to this PR
• msys2: topkg (indirect dependency) fails to build with an error related to findlib
• topiary, which is a dependency of catala-format, fails to build with a cargo error on debian 12, but is OK on 13
• conf-ninja fails its check on alpine

Of all these, only the first point (lint check) can be corrected by only modifying the files added here ; but I don't think it's really a problem ?

Of the other issues, I think they could be addressed if needed in other PRs:

• conf-ninja was broken on alpine by 3e37d16 (why the change @kit-ty-kate ?)
  samurai is the default implementation on alpine, and the ninja-build package actually doesn't install a ninja executable (which rightly makes the conf- package check fail) -- here is what the package show upon install

  * this only installs ninja to /usr/lib/ninja-build/bin/ninja
  * add that to your path to use it, or invoke it directly.
  * for most uses, you want samurai instead:
  *  $ apk add samurai
  * which has a "ninja" executable compatible with ninja.
  

• I don't think the other issues are critical

[kit-ty-kate]

Ah my bad i must have had the ninja-is-really-ninja package installed locally. I'm not sure why the PR was merged even though the package failed to build on alpine.

I just read the background discussions on Ninja vs. Samurai:

• https://lists.alpinelinux.org/~alpine/devel/%3CCAAOiGNwnzTomzOQ6YjH3t7VHmbfMRZUNXap8GM0Gy_mGS7aKhg%40mail.gmail.com%3E
• https://lists.alpinelinux.org/~alpine/devel/%3CBYZDB5LH4OVY.9FDVF5I3J954%40homura%3E

I'm not tooo convinced conf-ninja should make this choice for the user (distribution preference vs. consistency), but i guess it's ok. I'll open a revert PR

[AltGr]

Thanks! I don't really have an opinion on conf-ninja either, it would be fine with me if it used ninja-is-really-ninja instead ; FWIW, having samurai on our CI allowed us to detect missing dependency edges that vanilla ninja didn't mind. Also had the opposite case. But this is'nt really related to opam

Just updated the PR, our tags have moved with some fixes, and we have relaxed some version constraints so I'll go through the CI results again once it's done.

[AltGr]

ok, there doesn't appear to be new failures, except on cygwin where it passed before, but that seems unrelated (random failure ?). It might be due to the fact that we now allow ocaml 5.4, which we didn't before.

[AltGr]

Is it ok to merge this ? All CI errors have been examined and are not directly related to this.
Thanks!