ocamlPackages: fix eval and let ci check that it still evals

[jopejoe1]

The OCaml package set currently does not get tested by CI or build by hydra, let's change that so that no new errors are silently sneaking them self in.
Closes #277698
Closes #126934

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[vbgl]

A few packages do not build. It could be better to disable them. For instance ocamlPackages.janeStreet_0_15.typerep.

[jopejoe1]

Marked the ones failing to build with nixpkgs-review as broken

[jopejoe1]

@wolfgangwalther now with #426629 this would fail CI, as OCaml packages use a throw to chech which version they are compatible with Any idea how this could be otherwise handled in ocamlPackages so that it conforms to the better ci?

[wolfgangwalther]

now with #426629 this would fail CI, as OCaml packages use a throw to chech which version they are compatible with Any idea how this could be otherwise handled in ocamlPackages so that it conforms to the better ci?

I dealt with a similar cases in #426640 for luaPackages. I also have a local branch looking into more of these kinds of errors for python3Packages, which makes heavy use of disabled as well. I was experimenting with marking disabled = true packages as meta.broken at the same time. Depending on where the assert is placed, this could already be enough.

I'm still investigating these things myself, so there's not a 100%-ish "do it like this" answer, yet. Open to suggestions, too.

[vbgl]

To the best of my knowledge, packages marked with meta.broken are meant to be fixed, isn’t it?

[jopejoe1]

Would like to get this merged soonish if no-one else wants to take a stab at implementing this in a better way, following this comment from @wolfgangwalther.

[wolfgangwalther]

I don't see anyone coming up with a more principled approach, so let's do it this way.

Went through the changes, got some feedback.

[jopejoe1]

This gets way too many merge conflicts. I would really like to get this merged soon.

[wolfgangwalther]

I'm happy with commits 3 & 4. I think we are very close, the first two commits should be fixable. I'm happy to merge soon once they are.

[wolfgangwalther]

Thank you for this PR and all the other small fixes to release stuff / recursion etc. - very much appreciated.