I’ve lobbied for this change once already. Didn’t get the necessary support to go through with this.
There is some good news on the horizon though. @octachron is working on a structured output mode for the compiler. That would allow dune to detect warnings without failing on them. That would allow dune to successfully complete a build despite the presence of warnings. The presence of warnings would just decide what exit code the dune command returns with at the end.
Not that I care much however since unluckily I’m sometimes forced to use dune I’d just mention that this is only half the story. dune also tweaks the default set of warnings, a few of these are utterly annoying when you are trying things out.
I was told that the workaround is to use dune --profile=release (though that doesn’t suppress the noise, only the failures). That in turn is the slowest build, precisely when you want to have the shortest edit-compile-run cycle 
.
I think the “opinions” here are mixing code linting with code development.
Yeah, that’s a rabbit hole we regret ever going into. Unfortunately, getting out of it now and managing the transition is a huge hassle.
Utterly annoying in the sense you aren’t allowed to make progress once you encounter a warning? I agree. I don’t agree that it’s dune’s fault that the noise is overwhelming you. Managing how errors and warnings are displayed is the job of the editor, and I think users would be more annoyed if there were separate “lint” and “build” commands to juggle.
From a user interface point of view it’s likely going to end up being the same. Your editor may be smarter at displaying/hiding some warnings but then they will get ignored. So you will add an option to force their display…
Btw. you don’t need a new command, why not having a reasonable, user friendly dev profile and a lint profile (that you’d typically use in your CI if that’s your thing) ?
I’m not sure I’m following (probably because I don’t fully understand how ocamlc/dune/lsp interact with each other) but isn’t that the role of the lsp and how we configure it in the editor then?
As a user, for most languages/lsps, once I’ve done the proper set-up, I just assume the errors/warnings will show up in neovim without any further interaction.
Maybe the lsp client calls a lint function or maybe the fairies come and decorate my neovim buffer, but I’m not running the build command in the background to get the error messages.
I think our current dev profile was our attempt at “user friendly”
How is that not two commands though? You would need dune build --profile lint and dune build --profile dev.
that you’d typically use in your CI if that’s your thing
Wouldn’t it be annoying for contributors to successfully build a project locally, only to find out that it fails in CI 30 minutes later due to some trivial warnings issues?
The long term plan the dune team discussed before was to revert to using the compiler’s default warning settings. To appease the people that like dune’s current defaults, we’d introduce a way to define/install profile settings and allow users to enable them with a single stanza/command line flag.
Yes you are. You just aren’t aware of it 
lsp asks dune for the warnings flags for every source file to know what to display you inside the editor.
I thought there was a way to set your profile for subsequent builds.
Of course but then there’s only so much you can do with human factors. If you really think (I don’t) that this is a bigger issue than being able to focus and develop ideas with peace of mind (these warnings are distractions) then keep things as they are and simply give us a --profile=leavemealone build that can be used to quickly by-pass these terrible defaults.
I strongly agree with everything you said and I think this is excellent feedback! (Except that I would say ocamlformat is not opinionated enough. The strength of gofmt was that you couldn’t configure it, which makes the golang ecosystem beautiful to look at! Every codebase just looks the same.)
But if you don’t fail on warnings then you’ll only see them the first time you compile each file, I think, and it’s easy to forget you want to come back and fix them at the end.
Another possibility might be an editor short-cut that toggles a [@@@warning "-26-..."] at the top of your file. Then you could press that as soon as you were annoyed by a warning, but you’d notice it in the diff before committing.
Well… that’s justifying things on the very weird user interfaces choices made by dune. Personally I expect my build system to replay the build faithfully, including its standard outputs. I just ask it to make it faster, nothing more.
People have the wrong idea about this. I have no particular affinity for lisp and I doubt the rest of the team does either. It’s just that nobody to date proposed a reasonable alternative, let alone offered to help with the proposed massive project.
Anyone that suggests toml, json, and the like, is aware of only a fraction of dune’s feature set, nor is aware of the kind of contortions it would take to fit dune’s features into these simple formats. Anyone that suggests OCaml doesn’t have answers to the most immediate questions such as “how to produce proper error messages?”, or “how will it work in watch mode?”.
The door is wide open to do better than s-expressions. The team today just doesn’t have the bandwidth to design, implement, and transition the entire ecosystem to a new format.
Slightly OT, but as a counterpoint, let me just say that I do like the failure on warnings by default configuration of dune, even on debug mode. It can sometimes be a pain for quick prototyping - especially unused variables/bindings warnings, but pretty much every time I turn it off globally it ends up biting me later on.
I’ve found a good middle-ground nowadays is to never disable flags globally (which indeed requires a strange hard to remember env incantation that I have to look up), but rather prefix any files I’m debugging or hacking on with a [@@@warnings "-.."] annotation, which I eventually remove once I’ve finished changing the file. This leads to a quite natural workflow for changing a codebase while not taking all the safety checks off - if I notice a particular warning preventing my builds while hacking, I’ll just temporarily add a warnings annotation at the top of the file with the warning code from the error message (or use a more specific scope if I can localise the annotation to a particular function or module definition). This way the warnings don’t get in my way for the main file I’m hacking on, and if I happen to make changes outside of it, they are still enforced to be warning free, and thus less likely to be buggy.
When learning (the basics of) Elixir, I stumbled upon this site: https://elixirschool.com.
It’s a community-lead project, anyone can contribute a lesson. I learned a bit about the recommended SQL library (Ecto) that way, I got a very good experience out of this site.
See the link at the bottom of every page: " Caught a mistake or want to contribute to the lesson? Edit this lesson on GitHub!"
Reading this thread makes me think that a similar project could be useful to the Ocaml community. Does anything like this exist?
As I said earlier, my main gripe is documentation. So if there were a community-approved and centralized place to go where “if i want to do X, do Y”, I feel that’d really help newcomers (and possibly more advanced Ocaml programmers too).
I’m mainly web dev focused btw.
Yes elixirschool is awesome! I think the OCaml community can do the same.
I think newcomers, who must get acquainted with the language and environment, should benefit from a system that doesn’t get too much in their way by default (as opposed to having to handle warnings using whichever strange incantation) while they’re learning, and keeps displaying the same relevant data even when rebuilding.
In fact, when teaching, as programming projects and lab sessions remain quite small in LoC and number of files (< 10), we don’t need dune’s fast compilation but out-of-the-box: showing (without failing) warnings at each rebuild, fast dune utop, one short configuration file with almost no clauses by default (declaring the libs to use should be enough), easy testing (thanks to ppx_inline_test), no upwards exploration… We still want to use dune as it’s the most standard tool nowadays, supposing than we can charm a couple of students into keeping programming in OCaml even after the end of the semester
Nice! This should def exist for ocaml!
Sounds like an amazing idea and we would be more than happy to add such a section to ocamlverse. Feel free to contribute - we already have some articles on accomplishing simple things like this one. If you want to create a new category for this on the main page, that’s totally doable as well, but links to these pages could also be made on the ecosystem pages.
This is the danger of opinionated decisions. The first thing one needs to do before making such decisions is a) a survey of what OCaml users want b) a survey of what the industry does in such matters. c) what would the expectations of the average users (of all kinds) be? In this case, a decision was made to inconvenience the user for the subjective benefit of ‘better’ programming practices. It really doesn’t matter if one person or another finds this useful - the question is how this affects the community as a whole. The result of this decision was that many people including brand new users need to learn syntax they never wanted to deal with (to remove errors as warnings), in order to get the behavior they expected in the first place.
If we’re honest about this, what are the chances that dune would be using sexp if it had been born in a place that isn’t Jane Street? I’d say close to zero. Other alternatives exist and are used by every other language. But yes, the problem with opinionated decisions like this is that they’re very hard to change later. The extra burden of learning a second, uncommon language is probably stuck with us for good, unless a configuration tool that takes care of dune behind the scenes takes off sufficiently.
J’avais demandé des réponses en anglais mais toutes mes connaissances ont répondu en français. Pour ne pas déformer leur propos je m’abstiens de traduire.
J’en ai fait en école d’ingénieur et j’ai pas vraiment jeté l’éponge, à l’époque j’essayais de fabriquer des systèmes de simulation d’entités et on avait quelqu’un au club info qui m’a aidé en C++ et j’avais pas vraiment de motivation de faire plus d’Ocaml, mais j’en ai un bon souvenir et j’avais bien aimé
je m’en passe juste très bien
Je n’ai jamais essayé donc techniquement je n’ai pas (encore) jeté l’éponge. Le principal obstacle pour moi est l’absence totale de besoin pour mes propres usages de la programmation en général.
J’ai jamais voulu faire d’OCaml, j’ai été obligé d’en faire dans la cadre de mon cursus scolaire, j’ai simplement arrêté une fois que je n’avais plus cet impératif. Ce qui m’intéressait le plus à l’époque c’était la prog objet, pas la prog fonctionnelle, question de goût je suppose.
j’ai jamais vraiment essayé ocaml, et ça fait longtemps que je fais du haskell. donc c’est plus une question de confort, je ne saurais pas trouver de différence significative entre les deux langages qui aille plus loin que “je suis plus habitué à la syntaxe d’haskell”.
Honestly, I don’t see dune’s s-exps format as a real problem. Sure, it is a bit different from what other tools use, but other tools also all use their own syntax anyway: go is touted for its tooling, but go.mod uses its own custom syntax, YAML is un-parseable, etc. Maybe the most standard approach is to use some real language’s syntax – cargo build.rs is just Rust syntax, javascript tools typically use JS syntax – but I don’t think that there is a universal standard that newcomers would already feel familiar with at the start.