> On 26 Nov 2018, at 20:54, Julia Lawall wrote: > > Personally, I was in the end forced to install opam. But I don't want to > force my users to install it (to figure out how to get it to work, I had > to contact a member of Gallium - and my users don't have that > opportunity). I would prefer that they can just use the ocaml that comes > with their system package manager. > > Since opam is the recommended method of installation, couldn't there at > least be provided understandable instructions? That really seems like a > tougher time than what is necessary. > Dear Julia, dear all, Thanks for the helpful reminder that the opam and ocaml documentation needs a refresh. We’ve just gone through a fairly major release cycle with opam2 and dune1, and it’s to be expected that there are some inconsistencies. To clear up one misconception on this thread — opam is *not* the only recommended mechanism to get the OCaml compiler. We go to some trouble to ensure that OCaml is packaged up natively on the OS package managers where possible, and there is a list on the ocaml.org installation page with popular distributions. The problems begin when the user needs a particular version of OCaml, which is a common requirement for teaching. The system package managers typically lag in their versions (again, listed on the ocaml.org installation page). At this point, opam is indeed the simplest tool to bootstrap the precise version of the compiler and packages that you require, but at the expense of requiring an OCaml-specific tool. Now, I recognise the need for improving the installation instructions, and particularly so with step-by-step guides to getting things installed. However, I would implore those with complaints to register the inaccuracies on the opam issue tracker [1], so that we can at least learn about them and fix them just as we do with any software bug. [1] https://github.com/ocaml/opam/issues It’s particularly frustrating to see these threads erupt with pent up (and valid) annoyances from users that we could have addressed if someone had reported it. Even better, please do send in PRs with some suggested text for the website, and take some load off our overworked maintainers :-) For whoever said that my Ubuntu opam2 PPA is hard to Google, the process of creating it was roughly: - spend a few hours fighting with the Debian packaging scripts - get x86_64/i386/arm32/arm64/ppc64le all working in Launchpad - post on https://discuss.ocaml.org/t/opam-2-0-experimental-ppas/2446 to get no feedback whatsoever - eventually just push it live after one user gets back with feedback - wait for complaints to show up that its hard to find Without feedback, it’s very difficult to know what to prioritise, and Ubuntu is just one of many, many Linux distributions that we have to worry about. Japp Boender also wrote: > I'd like to chime in here - as the person responsible for doing most of the OCaml packaging for pkgsrc, I've noticed that I can hardly ever just update a package to a new version anymore - I'll generally also need to update the infrastructure as some sort of new build tool will have become involved, with all its attendant quirks, or someone will have decided to change the name of packages, or some other change will have occurred. Things seem to be in a constant state of flux, and thus packaging becomes quite time-consuming. This is indeed the result of progress on the tooling side. There’s been a lot of work in the last few years on deprecating older tools (camlp4, ocamlbuild) and moving towards modern alternatives such as dune for build and opam2 for publishing. Things are settling down now: dune is emerging as a well-maintained and portable alternative to the myriad of build systems that have been proposed in the past. The bootstrapping problems you mention should also have become a *lot* easier with opam2, since the solver is linked into the binary and no external aspcud is needed. If you do still run into any problems with fakeroots and such, please report them on the dune or opam issue tracker and we’ll take a look. Behind the scenes, there are other benefits from a consistent build system: cross compilation and Windows support are greatly improved now. Malcolm Matalka also wrote: > Is there a reasonable workflow for how to turn opam packages into > packages for existing OS's though? Currently it does seem like users > need to know about Ocaml to use things written in Ocaml, if only because > most of the focus has been on opam. Other OSs tend to have old > packages. Our goal (with my dune and opam developer hat on) is to provide sufficient metadata within a dune description of a project to automatically generate opam *and* upstreamable OS packages (from templates). This will look something like “dune @package” and really reduce the burden on developers and OS maintainers. I’d like, for example, the native OpenBSD packages to be able to be replaced by a mechanically generated version. See this issue for more: https://github.com/ocaml/dune/issues/1498 Julia Lawall also wrote: > The question is what to do after installing opam. Even if there is > nothing to do after installing opam, it would be helpful to say that. If > there is something to do after installing opam to get the ocaml compiler > for example, as opposed to just the runtime system, it would be helpful to > say that too. The documentation should be designed from the point of view > of the person who has never used ocaml or opam, never wants to use them > again, and has no contact with the ocaml community. Otherwise, people who > want to try some ocaml software, but are not actually forced to use it, > will just give up. I completely agree with this sentiment. I’m personally motivated to make sure ocaml/opam meet these standards, as we are moving to teaching using OCaml in the Cambridge University Computer Lab from next year, so I’ll definitely be proposing some changes myself :-) I’d love to hear from other teachers about the sort of environments you have to work in — we’ve been considering shifting to a combination of browser-based IDEs (for homogeneity across student laptops) and other systems. Finally, this thread might seem like it is full of complaints, but the tooling is steadily improving and leaving behind silent and satisfied users. Dune in particular has made as big a difference to our community as opam did when it was first released five years ago. At ICFP this year, the OCaml Workshop was full of industrial users who were thankful for Dune improving their day-to-day development, as well as the ecosystem of new tools such as ocamlformat, merlin, odoc and so on, and the Coq project is moving to adopt it now as well! I’m not suggesting we rest on our laurels, but as the year end holiday approaches, I would be delighted if users to email their favourite tool developer a note of encouragement to continue to work on it. And then file an issue to get the docs fixed :-) regards, Anil -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list Forum: https://discuss.ocaml.org/ Bug reports: http://caml.inria.fr/bin/caml-bugs