Dependency hell makes it difficult to use OCaml for meaningful work

[avsm]

@davesnx

I get the intention, but think about it from the perspective of someone learning OCaml who just wants to build a small CLI tool. They’re not in a position to debug a dependency they barely understand yet, and that was never their goal. They came to build something, not to maintain someone else’s library. We should meet people where they are.

And where they ended up was a working installation of the libraries they requested. This whole topic could easily have been “OCaml successfully gave me a working environment; now I’m wondering how to use the very latest compiler” but the OP seems to have been in a bad mood and decided to spread their malaise.

I agree that we could do with some support in opam to make the compiler package invariants clearer in the UI: I have also noticed the lack of an invariant when using local switches, but doing so is as simple as:

> opam switch create . 5.4.0
<><> Installing new switch packages <><><><><><><><><><><><><><><><><><><><>  🐫
Switch invariant: ["ocaml-base-compiler" {= "5.4.0"}]
...etc

(but I always forget to specify the compiler and end up without an invariant)

I’ve recently been coding in other ecosystems like npm and have observed exactly the same problems with upper bounds (just try upgrading to Vite8 and rolldown in pnpm). In those cases, my coding agents cut through the issue in minutes and helped me find the right command line magic. OCaml is no different in this regard: all the AI agents work just fine in my experience. What these agents cannot do, however, is to encourage constructive public communication about issues found that makes volunteer maintainers want to help a stranger out.

@nojb

I wonder if the subject would have come up at all if OPAM could deploy relocatable binary artifacts (deployed from the cloud or even purely locally),

We’re getting there (well, @dra27 is). The latest opam package is “relocatable” which packages can issue a conflict against if they are not relocatable. After that, binary caching will be a breeze until you get to third-party system shared libraries being upgraded under our feet by the system package manager, but we wouldn’t want life to be too easy right? @mtelvers has also built a system that can bulk build all opam packages in 30 minutes on one machine, which unlocks the ability to build quick binary snaps on Linux/amd64/arm64. macOS and Windows will remain a pain.

@nojb

people building serious software in OCaml generally take a rather sober approach to their use of third-party libraries (as they should), precisely because of this issue: you don’t control the third-party library and no amount of effort in the UX of the package manager will shield you from breaking changes/abandonment/etc. I don’t think any other language has discovered a magic solution to this basic fact.

My 22 year old PhD OCaml code still compiles today with the only breakage being the switch to safe-string! Sadly aging the code hasn’t improved the quality of what I wrote back then.

I entirely agree about taking responsibility in ‘industrial’ software of dependencies. I wrote up our experiences in using OCaml in Docker in this year’s ICFP and that uses a monorepo with manual imports from opam every so often. This is necessary not just for basic security hygiene of inspecting third-party updates, but also for determinism and calculation of licensing strings for products embedding other people’s code.