esy is consistent and reproducible, not as much as nix, but quite close, but it has sandboxed environments, it generates huge envs, it’s okay to have the ones needed for PATH, most packages don’t define anything on
/bin so it can be small,
OCAMLPATH on the other hand is huge.
Agreed that dune isn’t the final world on build systems, but to achieve the advantages mentioned in the RFC, it’s a better solution.
The RFC is not about the code, or about what it is doing, the RFC is a statement and anyone making one should be conscient about this, an RFC approved by the OCaml core it’s an statement saying that this is how the OCaml team is going to do it, and by side effect how users should do it. It’s not something that I as someone who is working on tools to other developers can just ignore.
So yes I can still keep using ocamlfind in the same way that you can still keep not using dune for all of your packages(which I deeply like, just regret that they’re not using dune), but that’s not the point. We have a standard already and it’s a working one, which is ocamlfind.
As @jeremiedimino pointed out, the RFC is essentially saying that the
findlib.conf is a standard that is meant to disappear and the reason seems to be because of the RFC. The RFC is not breaking code, but it is changing standards, one standard which is already working and defined by ocamlfind.
Ok, I will try be clear, I think the current situation is good enough, the standard is de facto ocamlfind. And moving to the RFC doesn’t add considerably advantages with fast modern IO.
I will use some JS analogies because TC39 is a well established institution who sometimes makes things harder just by defining things, not a single line of code needed but huge movements and changes in workflows happens because of that, they don’t need breaking changes to do a breaking change.
What is wrong
Changing ocamlfind to the standard defined by the RFC, in the same way that changing from commonjs to esmodules was a mistake in the JS ecosystem, the current solution is not perfect but it’s already there, no work needed.
What is the right direction for me
A specification, where it is mostly compatible with ocamlfind, removing the need for the binary but reading the findlib.conf, saying how a build system / package manager should interact. Not a single line of code needed.
Then we can have a list of specifications endorsed by someone who is an authority(maybe the OCaml team?) and a list of tools that implement them which are verified and listed by popularity. That means that right know dune is the standard that “everyone” is using for their build system, same is true for opam and packages.