Hi
Over at lobste.rs there is some discussion on the following blog post: Getting OCaml Through the Eye of a Needle
Basically it’s about the ups and downs when using and installing Ocaml packages.
Personally, I’ve had similar experiences, but this article is really well written. The author shows great technical knowledge and I think he tries to be fair.
What do you think?
Discussion on lobste.rs: Getting OCaml Through the Eye of a Needle | Lobsters
TIL about lobste.rs. (Since can’t reply without being a member, and some of that discussion seems better on discuss, I’ll post here)
What Jean posted seems both normal and sad. Spoiler alert: If you can’t read the post, the recommendation is:
not to use OCaml for webdev except in narrow cases
Since I did something similar at DkCoder 0.2 - Scripting in OCaml - #2 by jbeckford with the DkSubscribeWebhook example, I have some takeaways:
glibc on Linux is a thing. I use dockcross for that (essentially the same thing that binary Python wheels use), and you can use dkml-workflows in CI if you’d like a guided setup for existing OCaml projects.core, but I don’t think we have a good candidate yet that can cover the (mythical?) 80% of use cases.opam (after it gets through its current priorities).dune configuration value.In the meantime, I can practically apply the above takeaways as I’m developing DkCoder:
.so, .cma, etc.) for the end-user with OS-specific portable build mechanisms (dockcross for Linux, MACOSX_DEPLOYMENT_TARGET for macOS). But today I can’t reliably reproduce the .cma artifacts.scp-ing static binaries is much nicer when you don’t have CI/CD pipelines.There seem to be quite a bit of FUD floating around with opam and the opam-repository these days. Perhaps we do a bad job of explaining the virtues of the current system.
I recently got this article in my feeds and not only does it say things I’m 99.9% certain are wrong, like:
Another issue I noticed is that Opam sometimes installs non-OCaml libraries, like PostgreSQL, without asking, if a specific library requires it. This situation feels a bit odd.
It also largely ignores all the QA on the eco-system the opam repository entails, notably to ensure smooth OCaml compiler release. QA that is likely responsible for the stability of the tools he’s using in the first place.
As the maintainer of approximately 40 packages on the opam-repository I can’t stress enough how golden it is when @kit-ty-kate shows up with a PR to fix your package for an upcoming OCaml release, not even complaining that you are not using dune :–) Not that breakage is generally widespread, the OCaml system is extremely stable, but some of the stuff I have relies on advertised brittle bits of upstream (toplevel plumbing, compiler artefacts reading etc).
This to say that a lot of unglamorous work is going on behind the scene that people with blogs seem to be largely unaware of. And yes it’s cool to be able to specify your dependencies by just adding random URLs from the internet but in the long term it’s likely to be uncool for your software in a way or another.
And for those people who are unhappy because it takes time to release packages on the opam-repository then from my perpsective I think there are few points to consider:
opam-repository is worthwhile. Then don’t complain about the time it takes. Either accept the wait or try to give a hand at curating the repo additions or the issue tracker to speed them up.opam-repo-ocamlnat and distrib-crutch.opam that you can use as a blueprint.Bref, I think a little bit more appreciation should be shown to the opam developers and opam-repository maintainers for the unglamorous work that goes unoticed when everything works smoothly – which as far as I’m concerned is most of the time. Many thanks to them.
Isn’t that the exact reasoning behind depext: opam - opam-depext
It can query OPAM for the right external dependencies on a set of packages, depending on the host OS, and call the OS’s package manager in the appropriate way to install them.
Sounds like it automatically installs system packages for you.
What do you mean exactly? Do you mean this article? Or are there any other articles that are spreading FUD around Opam? I’m not aware of such a trend.
That is one article, and is more about praising Nix than it is about Opam.
I fail to see where this article would suggest anything otherwise. Did you really read the entire thing with an open mind?
opam will ask you to confirm unless you explicitly pass the flag to it to automatically answer “yes”. And it will give you options: (1) it installs the package with your agreement and your help (e.g. if password is needed); (2) it lets you take an excursion to manually install what’s needed and then resumes the installation process; (3) it lets you re-do the installation with ignoring the external dependency, e.g. when it’s satisfied in a non-package-manager-aware way.
Exactly. So not only does opam never install non-OCaml libraries without asking, it also suggest you how to interact with your other package systems in order to be able to install the OCaml software you want to install (rather than making the error of starting to package them with a closed world mentality).
I fail to see how this is an “issue” with opam, I’d say it’s an excellent, user-friendly, feature and is actually excerciced to make sure everything runs smoothly on a diversity of platform when you submit to the opam-repository.
Rather the uninformed[1] commentary that these articles generate, but then.
Did you really read my message with an open mind ?
Hence my suggestion at explaining better why things are how they are. ↩︎
I think the issue of OCaml packages refers to more than just opam and opam-repository. As far as the work done on opam-repository is concerned (being an actor myself), it must be understood that these members cannot give an opinion or a direction on the choice that the author/maintainer of the package may have made despite all the considerations that may be known from the ecosystem. In other words, the members can be aware that there may be situations (clash of module names, reverse dependencies, incompatibility between types, etc.) that the author/maintainer may not have taken into consideration. As such, we can spend a really non-negligible amount of time helping and assisting these authors/maintainers (sometimes for free). However, they remain authors/maintainers and we may not agree with their solutions (based on our experience) but this does not bias our choice to press the ‘merge’ button and accept the release.
To describe the situation factually, it’s “normal” that a package that hasn’t had a release for almost 1 year (and whose distribution isn’t all that standard compared to the first release: Dream — tidy, feature-complete Web framework by aantron · Pull Request #18536 · ocaml/opam-repository · GitHub) may no longer be installable today. The team clearly doesn’t have the time or resources to ensure that all packages are installable throughout the year. So there is also work expected by maintainers and authors of packages for which opam-repository members are obviously not responsible.
And that may be the problem. You can give a factual description of the ecosystem, as this article does very well. But beyond an honest assessment, we can also look at the reasons. Why hasn’t this package had a release in almost 1 year? Why does part of the ecosystem seem to be continuing to evolve, while this first package seems to have remained in the past? Why are there esy and opam - and why are we being led to consider these two solutions?
To answer one of these questions, it may also be time to consider the financial resources that are available or could be made available to help these authors/maintainers so that they can continue to maintain and develop these packages. This is often the nerd in the war. Nobody works on “love and fresh water”.
The financial aspect is not the only parameter. Behind these questions, there are also social considerations (interactions between authors/maintainers because their projects depend on each other). These interactions are also a burden that may or may not be healthy depending on people’s affinities. And this burden can be so great that we refuse to give even more of our time to our projects. In this respect, we also need to question the community’s ability to be inclusive and maintain good relations between all the authors/maintainers.
A technical and honest assessment of OCaml and its ecosystem always hides a forest of social questions and it seems to me to be healthy to pose the problem without responding with another technical solution.
I’d like to make it clear that I’m in no way blaming the author of Dream (being French, I may not have the subtlety to match the words written here with my thoughts and I’d really like to avoid offending anyone) as I myself took part in the project, which depended on one of my projects. I’ve always had cordial and pleasant exchanges with the author (and I’d like to imagine a future where these exchanges can continue).
How do you think about financial sponsoring as a possible part of the solution?
It would be great, if there was a possibility where users like me could sponsor:
and/or
over some kind of trusted intermediary entity (Ocaml Foundation)
You can do it today if you want through GitHub.
I find this post a little strange. Dream is clearly marked alpha so criticizing feels unwarranted IMO.
caqti-study was also briefly mentioned, it’s my modest contribution in the form of a tutorial introducing OCaml + Caqti and an ongoing work which I intend to finish. If something wasn’t working for the author, he could have simply filed an issue so that I could improve it, whatever he stumbled upon.
Anyway, I don’t think there’s much too say. Yes the OCaml web experience could be better if more people were working on things 
Side note I’d like to highlight that the OCaml software foundation contacted me many months ago to propose funding me to keep working on this tutorial. Although I haven’t been able to make time for this project as much as I would like, I felt pretty touched by this offer.
I saw this post on hacker news this week and just wanted to share my experience trying to do something similar.
I’ve been building a CRUD app in my free time with ReasonML, Dream, and Caqti (using SQLite). My professional experience is python and typescript for webdev with a bit of C++, and some rust in my free time.
I was a little disappointed the author of the article didn’t actually get to building an app. I had a little bit of pain with the project set up, but mostly trying to work out how to pin a GitHub version of a package so I could use Dream’s reload middleware (I guess this is an example where the Dream docs are ahead of what’s on opam). But other than that it’s been pretty smooth sailing.
The development experience has been great, which for me comes down to having a fast compiler with a good type system. Coming from python where types are just so much work for not much gain, it’s great being able to lean against the compiler when I want to refactor things or work out data transformations. Even with typescript it just feels like a lot of overhead to maintain all your types correctly? With ocaml I feel like refactors in particular have been faster and easier than any other language I’ve used. Granted my project is pretty small.
Dream itself is great too, I briefly looked at trying to build the same app with rust and axum but it really seems you need to assemble your own stack from smaller packages (e.g. find a session management package that works with axum). This seems much more prone to the stale package issue mentioned in the article.
ReasonML’s JSX was the decider for me to choose that syntax over ocaml, and coupling it with Tyxml for compile time checked html has been great. I’m using htmx with this which is working pretty well.
Mustache and zipc allow me to export batches of .odt templated reports without touching the disk.
I think the biggest issue I can foresee at the moment is having all my sql written as strings with no coupling to the types I’ve declared for them (I’m just using Caqti here). There’s been a few times already where I’ve discovered mis-types at run time.
Overall I’m really enjoying working with this stack and I appreciate the work that’s gone into building and maintaining the ecosystem.
Esy appeals to me very much, as it manages packages for your projects in an isolated environment, instead of having all your dependencies smeared together in a global one.
This part reminded me of one of my early uncertainties about Opam
Unlike the author I did manage to find opam switch but I wasn’t entirely sure how to use them the way I was expecting to
However the OCaml website docs have improved quite a bit since then and it’s now only two clicks from the homepage to Learn OCaml and then to Introduction to opam Switches · OCaml Documentation helpfully listed under the intro getting started section
So kudos for that 
Hi, thanks for all the comments! 
My goal with the blog post was to explain what a person new to OCaml would encounter if they wanted to create a web service in OCaml. For what it’s worth, I picked Dream because a lot of people seem to recommend it, the documentation is awesome, and out of all frameworks listed on Is OCaml Web yet? it is at the top with most GitHub stars. Is that a good choice? Well, based on the research I did, it seems like a good choice – my only issue is that the main branch is a little ahead and the documentation points there, and I didn’t know how to pin the latest git revision. I’ve had very little issues with Dream itself except for that.
I found caqti-study great, thanks for you efforts! No issues with it Thing is, since I installed Dream which referred to Caqti 1.9, caqti-study itself didn’t compile for me. The only issue was that I thought I had 2.x installed, when I didn’t. If anything, the blame’s on me because I didn’t do opam install . --deps-only in the project before trying to compile stuff – I am used to projects being isolated and dependencies being fetched automatically if not already present.
I’ll get there eventually. My hope is to have a blog post about that too, though I got some suggestions on how to set up a reproducible project I also want to at least take a look at.
This is a little bit off topic, but I’ve found it helpful to have a test database and make a test for all the queries I have, regardless of language. In that way, I can be more confident that the table columns have the right type and that the query is syntactically correct.