0

What are the available solutions/practice to reduce the moving pieces and select some precise set of dependencies which were vetted somehow (nix style hash, freeze file, switch signature, etc..) ?

Context :

I checked out Base, and dune build it. I (expectedly) ran in a few issues by choosing the bleeding edge (despite opam repo add janestreet-bleeding https://ocaml.janestreet.com/opam-repository), which leads to my question about the OCaml ecosystem as of now.

Chris
  • 26,361
  • 5
  • 21
  • 42
nicolas
  • 9,549
  • 3
  • 39
  • 83
  • This sounds like the kind of thing to ask over on https://github.com/janestreet/base/issues? I'd imagine they appreciate being able to talk to you about what went wrong so that documentation can be updated etc. – Mike 'Pomax' Kamermans Dec 21 '21 at 21:51
  • It seems to be (cf https://github.com/janestreet/base/issues/114) but my question is more general and applies to any ocaml project – nicolas Dec 21 '21 at 21:52
  • I'm not sure I see how it applies to "any" ocaml project? You're having Janestree's Base-related problems that you most certainly wouldn't have with the standard ocaml release, so the question is pretty tailored to this one specific flavour? – Mike 'Pomax' Kamermans Dec 21 '21 at 21:55
  • 1
    controlling dependency versions of a project happens not only for the specific project `base`, but for any project. This happens in any languages, not just ocaml, and usually each have a way to freeze those dependencies. it's "lock files", or nix derivations, etc. and there's usually a practice more or less formal for each. – nicolas Dec 22 '21 at 07:40
  • 1
    [esy](https://esy.sh/) offers lock files, and project isolation. `opam` does neither as far as I'm aware. – glennsl Dec 22 '21 at 09:00
  • 2
    opam does have `opam lock` and local switches. (I don't use dependency locking and cannot comment further). – octachron Dec 22 '21 at 10:23
  • Indeed, seems `opam lock` used to be a plugin, but is now integrated. There's still no mention of it in the manual though. Local switches are mentioned, but not really explained. Some room for improvement there I think :) – glennsl Dec 22 '21 at 11:14
  • opam (like most package managers I guess) allows packages to specify upper bounds for the versions of their dependencies. This is largely not done in the wild (which I regret). Doing that implies bumping your package regularly even with no change, when new versions of your dependencies come up and you have tested your package works with them. That’s verification work you’d want to be done anyway, but many packages just don’t have the manpower for that, and most often releases are backward-compatible. [Stupid idea: let package authors flag some of their versions as *not* backward-compatible?] – Maëlan Dec 22 '21 at 11:24
  • 1
    @Maëlan there was long and heated debate about that in the haskell ecosystem. as you pointed out, tooling and manpower could overcome the dilemma. That problem can also be vastly reduced by having versions for **sets** of packages (cf stackage.org), at the cost of excluding some potentially working combination. But this brings a benefit too, as it provides some aim for library author to be compatible with (say stackage LTS 18.19). In production Ocaml, I imagine that's what happens, by using the compiler version as a global version numbering, for libraries to be mutually compatible with (?) – nicolas Dec 22 '21 at 12:03
  • 1
    @octachron that seems what I was looking for ! thanks. documented here : https://opam.ocaml.org/blog/opam-2-1-0/#opam-lock-files-and-reproducibility Now I just need to ask those lock files I guess – nicolas Dec 22 '21 at 12:08
  • Without those lock files, the library (`base` in this case) in its version`v0.14.2`, paired with the public switch `4.14.0-base` compiles successfully. but that's (almost) fishing. – nicolas Dec 22 '21 at 12:39

0 Answers0