Re: [Caml-list] Build-/Installation-Tools - not enogh of them?

[Anil Madhavapeddy <anil@recoil.org>]

[-- Attachment #1: Type: text/plain, Size: 7434 bytes --]


> On 26 Nov 2018, at 20:54, Julia Lawall <julia.lawall@lip6.fr> 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

[-- Attachment #2: Type: text/html, Size: 16392 bytes --]