3 ms·

I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing bui

by rwmj 2y ago

I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc). I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.

toolslive 2y ago
Whenever I ran into trouble (up until ~2019) with dune I would first get it to work with (ocamlfind) ocamlopt, look what the lowest level needed to look like, and then reverse engineer to make dune spit out the same thing. I would hope things have improved since
cdaringe 2y ago
I cordially disagree. I do not find dune weird or obscure. It’s formally part of the OCaml platform: https://ocaml.org/platform https://ocaml.org/platform, which I think negates at least the obscure bit. It was “new” to me for a hot moment, and it’s certainly a less common format for config files (s (expressions)). However, what I see is a tool that solves concrete problems that uses a declarative, structured format (not very weird). It also has pretty great docs!
- rwmj 2y ago
  I have to deal with dune across all the Fedora OCaml packaging (something like 200 different upstreams) and it's quite difficult to deal with. Not the worst build system out there, but makes me a bit sad every time I have to modify something in a project.
- RandomThoughts3 2y ago
  Dune is part of the platform mostly because it was there and was the tool used and developed by Ocaml biggest corporate user but it’s hard to disagree with it’s weird (s-expressions in a non LISP, really?) and a bit obscure. Esy seems to solve most of these issues at the costs of a tie-in to npm.
- mattpallissard 2y ago
  I don't find it particularly weird or obscure either. I've had to speak over the FFI a handful of times and it was honestly a better experience than go's story (which also wasn't terrible IMO). But I also recognize that I have a high pain tolerance for build systems. I will conceed though, the Tarides folks know their shit when it comes to OCaml projects.
jasperry 2y ago
The black-boxiness of dune has frustrated me as well, but to its credit it does a lot of work for you. Its biggest problem might be documentation; at least the last time I looked at it, there were only very basic examples plus a listing of the keywords with terse descriptions. The art of writing a reference manual that actually explains how the software works is almost lost, it seems.
- qlfa102 2y ago
  > The art of writing a reference manual that actually explains how the software works is almost lost, it seems. The original INRIA docs are also better than the new things on ocaml.org. Literally the only issue with the "old" INRIA pages was the poor quality of the mailing list archive, the rest is great! I want my tar archives and docs from INRIA. If I was rich, I'd pay for a grant to update the "old" documentation.
yawaramin 2y ago
Yeah but you've been using OCaml packages by wrapping them up as rpms (I assume). This is not very scalable ;-)
- rwmj 2y ago
  I often hear this misinformed remark from people who only ever need to share software within a single company or just upload something to their one web site. For us, RPM solves a very important problem: How to develop and test the exact bits that we will ship to customers, where they will install and integrate that software on their own servers, in a huge variety of environments. For this while RPM is not completely ideal in all ways, it's vastly better than other OCaml tooling (apart from .debs I suppose).
  - yawaramin 2y ago
    My comment was more pointing out that the reason you didn't need to use opam is because you package your dependencies yourself, with rpm. And that most people won't be doing this because in general there is a large set of packages out there which can potentially be used in the ecosystem, and growing larger day by day. So like I said, it's not scalable for others to do what you're doing and in most cases opam is the way to go. I am sure you have specialized needs and find that rpm is best suited for them, although I don't see how opam fails to solve this issue either (anyone can maintain their own opam repository with locked down versions of packages to match exactly what they need to ship to their customers), but that's a separate argument.
    - rwmj 2y ago
      We're shipping more (by value) OCaml software to end users than probably anyone. To say this is "specialized" is absurd. Also opam doesn't do what we need, showing you don't understand the requirements.
      - yawaramin 2y ago
        Guilty as charged, I don't fully understand your requirements because you haven't specified exactly what they are, you've spoken in fairly abstract terms that seem like they should be achievable by a locked-down opam repository. Of course I'm sure now that you have many other requirements which are not achievable by opam, but when I speak about 'specialized' I am thinking about the vast majority of OCaml development and teams, not the 'value' (which I don't doubt, I am sure you are shipping great OCaml software). For example, avionics systems are developed in a specialized way due to rigorous safety requirements, yet they offer critical global value. They're still specialized requirements though because most software is not developed like that.

by rwmj 2y ago

toolslive 2y ago

Whenever I ran into trouble (up until ~2019) with dune I would first get it to work with (ocamlfind) ocamlopt, look what the lowest level needed to look like, and then reverse engineer to make dune spit out the same thing. I would hope things have improved since

cdaringe 2y ago

I cordially disagree. I do not find dune weird or obscure. It’s formally part of the OCaml platform: https://ocaml.org/platform https://ocaml.org/platform, which I think negates at least the obscure bit. It was “new” to me for a hot moment, and it’s certainly a less common format for config files (s (expressions)). However, what I see is a tool that solves concrete problems that uses a declarative, structured format (not very weird). It also has pretty great docs!

rwmj 2y ago
I have to deal with dune across all the Fedora OCaml packaging (something like 200 different upstreams) and it's quite difficult to deal with. Not the worst build system out there, but makes me a bit sad every time I have to modify something in a project.
RandomThoughts3 2y ago
Dune is part of the platform mostly because it was there and was the tool used and developed by Ocaml biggest corporate user but it’s hard to disagree with it’s weird (s-expressions in a non LISP, really?) and a bit obscure. Esy seems to solve most of these issues at the costs of a tie-in to npm.
mattpallissard 2y ago
I don't find it particularly weird or obscure either. I've had to speak over the FFI a handful of times and it was honestly a better experience than go's story (which also wasn't terrible IMO). But I also recognize that I have a high pain tolerance for build systems. I will conceed though, the Tarides folks know their shit when it comes to OCaml projects.

jasperry 2y ago

The black-boxiness of dune has frustrated me as well, but to its credit it does a lot of work for you. Its biggest problem might be documentation; at least the last time I looked at it, there were only very basic examples plus a listing of the keywords with terse descriptions. The art of writing a reference manual that actually explains how the software works is almost lost, it seems.

qlfa102 2y ago
> The art of writing a reference manual that actually explains how the software works is almost lost, it seems. The original INRIA docs are also better than the new things on ocaml.org. Literally the only issue with the "old" INRIA pages was the poor quality of the mailing list archive, the rest is great! I want my tar archives and docs from INRIA. If I was rich, I'd pay for a grant to update the "old" documentation.

yawaramin 2y ago

Yeah but you've been using OCaml packages by wrapping them up as rpms (I assume). This is not very scalable ;-)

rwmj 2y ago
I often hear this misinformed remark from people who only ever need to share software within a single company or just upload something to their one web site. For us, RPM solves a very important problem: How to develop and test the exact bits that we will ship to customers, where they will install and integrate that software on their own servers, in a huge variety of environments. For this while RPM is not completely ideal in all ways, it's vastly better than other OCaml tooling (apart from .debs I suppose).
- yawaramin 2y ago
  My comment was more pointing out that the reason you didn't need to use opam is because you package your dependencies yourself, with rpm. And that most people won't be doing this because in general there is a large set of packages out there which can potentially be used in the ecosystem, and growing larger day by day. So like I said, it's not scalable for others to do what you're doing and in most cases opam is the way to go. I am sure you have specialized needs and find that rpm is best suited for them, although I don't see how opam fails to solve this issue either (anyone can maintain their own opam repository with locked down versions of packages to match exactly what they need to ship to their customers), but that's a separate argument.
  - rwmj 2y ago
    We're shipping more (by value) OCaml software to end users than probably anyone. To say this is "specialized" is absurd. Also opam doesn't do what we need, showing you don't understand the requirements.
    - yawaramin 2y ago
      Guilty as charged, I don't fully understand your requirements because you haven't specified exactly what they are, you've spoken in fairly abstract terms that seem like they should be achievable by a locked-down opam repository. Of course I'm sure now that you have many other requirements which are not achievable by opam, but when I speak about 'specialized' I am thinking about the vast majority of OCaml development and teams, not the 'value' (which I don't doubt, I am sure you are shipping great OCaml software). For example, avionics systems are developed in a specialized way due to rigorous safety requirements, yet they offer critical global value. They're still specialized requirements though because most software is not developed like that.