The devil is in the details. I remember hitting odd hard-coded stuff e.g. on mt predicates. Also the behaviour w.r.t. includes when you use packages does not seem to be documented there (and in general what happens when you use packages in the different phases).
I mentioned in the first message, using the environment to setting up libraries, I gave examples on why it makes debugging build failures harder, because now you have two different environments for each target, so copying a command is not enough anymore, why setting up cross-compilation harder and that we will probably still need to rely in a solution like findlib so it adds more complexity instead of removing them.
And also itās not only a technical argument, itās an ecosystem decision, itās about community, saying ābut it doesnāt break anythingā is just not the complete story, because in practice it does. Read the example of TC39 breaking the JS ecosystem with ES Modules and how webpack does all sorts of magic to be able to handle it, and they didnāt ship a single line of code.
Yes itās a very small step adding a bit of complexity and sending a message to the community that the standard changed. Iām not saying the end result in 10 years will not be better, but will it be better in 6 months? 1-3 years? A change like this is not small.
Iām not taking credits for anything that isnāt my work and donāt think that I donāt remember the people that were here before me, Iām just saying that stuff is already working with a package manager, only that.
And this argument was made because the solution of opam-monorepo chosen by MirageOS 4 is just not going to be affected by anything, because it is a workaround for opam, instead of relying on packages it is essentially vendoring all the packages in the environment and delegating the work to dune. Yes it works and will not be affected by basically anything, as itās just dune.
But not a solution to the root problem, which is the lack of cross-compilation on opam. If that was not the case, there would be zero needs to use opam-monorepo and this is why I say itās not orthogonal.
Libraries as described by the RFC are directly connected to the compiler, build system and package manager, so it definitely affects cross compilation. If you still have a package manager.
Iām not capable of building a little unikernel with esy, Iām capable of building almost anything, I got Revery which uses all sorts of C deps to work(including different C compilers), got really old deps like camljava to work on Android 10, esy to build itself to iOS, Android and FreeBSD. And as soon as I have spare time the goal was to build Tezos using it. This is not small and not limited to opam, topkg is also supported. Also it manages C deps too, so a bit more powerful than dune + opam-monorepo, without any environment mess needed.
BTW Iām not the author of esy, not even a maintainer of it.
It makes me wonder if there is already this specification, if we shouldnāt just embrace it instead. Itās well documented, a standard and already implemented in multiple places.
Great, we have an amendment to do and avoid that others have the same problem, this is progress, no step back needed.
If thatās really your only gripe then the OCAMLPATH could be bootstrapped via a configuration file rather than at configure-time like itās done now in the RFC. I donāt see this as a big deal.
Thereās benefit in having a simple notion of library, how it is to be installed and used by other tools. And thereās also benefit in the OCaml toolchain understanding it. I think the RFC is pretty clear about why this is the case so I wonāt repeat them here.
And yes itās an eco-system decision, nobody is trying to hide that. But no it does not try to break the eco-system, it tries to gradually simplify it.
6 Likes
Thatās not the only one, that is a problem, that will make people life harder on the long run, incentivizing OCAMLPATH overall will lead to problems. But even then, my gripe is with the RFC deprecating ocamlfind.
I agree, there is benefits in a simple notion of library, but it already exists, following ocamlfind. This is not new, itās an already solved problem, not perfectly solved, but solved.
About the benefits mentioned in the RFC:
- Is that even desirable? Why isnāt gcc introducing libraries support on the compiler? But I agree with the dynlink problem deeply, and we need to address it, but the RFC is not only about it.
- It is addressed by dune removing the direct dependency on the ocamlfind, so now you just need ocaml and dune.
- Iām not sure it is even an advantage, having multiple namespace for different things seems reasonable, opam packages may include other things besides of ocaml libraries.
- Agreed, but the convention already exists, which is ocamlfind.
- Itās mostly already in place, if you look at libraries generated by dune theyāre basically always a single library per folder.
- Agreed, but this is why most libraries are named the same the opam package, it could be better but that can be done on opam side.
An important thing, as a user I didnāt even knew ocamlfind until I started to look on the cross compiling problem, because dune already solves this for me, so 2 and 4 itself is mostly pointless. So as an end-user and a tool developer, I cannot see how having a new standard will make my life easier. Essentially most of the benefits mentioned are addressed already by dune and ocamlfind.
By adding a new standard it almost always will not be simplifying things. xkcd: Standards
Telling everyone to change the standard of what is a library, is a breaking change. And trying to deny it by saying ābut your code will keep workingā is not taking responsibility for the change. Again in the same way that TC39 didnāt take responsibility for breaking the JS ecosystem which they did.
And remember that the RFC has a section dedicated to what dune will do.
1 Like
It seems that your world view of the OCaml system is limited to dune. Thatās fine.
But personally nowadays I start all my projects with an (unreleased yet) best-effort build tool. So just be mindful that people may use the OCaml system in different ways than you do. Once you factor that in, most of your rebuttals fall.
Also Iām getting quite annoyed at your repeated suggestion that the RFC is not taking responsability for the changes it introduces while in reality it precisely describes how the existing tooling that most people use is made to be changed to become compatible and take advantage of the definition. I think your stance is disrespectful for all the work that went into designing and prototyping this and I have to say, Iām not interested in discussing this with you any further.
3 Likes
Is this still being worked on?