Which (ocaml, opam, opam-bundle) version combination "just works" (tm)?

Community
,
1

Hello,

I need to package some software for end-users (you cannot ask them to install ocaml
and opam by themselves; this is for developpers).
The software in question is this one:

I would like to use opam-bundle:

However, every time I use it, the created bundle cannot be installed.

I would like to know which combination of (ocaml-version, opam-bundle version and opam version)
is stable an production ready.

Regards,
F.

2

Sorry if this is an obvious question, but why not distribute binary executables for Linux/Win/Mac? Nowadays with the official OCaml Docker images, it should be quite possible to set up CI builds in GitHub or whatever CI service you prefer.

1 Like
3

Providing a virtual machine images, or a docker image, would be another solution.
But, an opam-bundle is less work on my side, so I would prefer this solution.

I might provide a docker image at some point, if enough users bother me…

4

I am unsure about the portability of ocaml executables, so I was not considering this option.

5

Should be quite portable, unless trying to port to Windows and certain Unix-isms like fork(2) have been used. But in terms of what binaries will actually work for end users, I think it’s reasonable to target a limited set of OSs, e.g. macOS latest, a couple of popular Linux distros, and Windows if possible.

GitHub Actions provides virtual runners for these OSs, and allows you to install custom software e.g. opam and then use them in your builds: Customizing GitHub-hosted runners - GitHub Docs

It’s not terribly efficient–opam will need to be installed on each build–but if you release every week or so, for example, it shouldn’t be too annoying.

EDIT: I totally forgot about Set up OCaml, a custom GitHub Action which does all this for you, with efficient caching!

EDIT 2: GitHub action that creates a ‘release’ and uploads artifacts from the build to it: Create Release · Actions · GitHub Marketplace · GitHub

So, in GHA you can build the OCaml binary, wrap it up in a .tar.gz along with the Python script and README, then upload the archive to the release page, Releases · UnixJunkie/FASMIFRA · GitHub

6

Indeed — and thanks for your interest — opam-bundle needs an update. There is a pending PR for opam 2.1 (opam pin opam-bundle git+https://github.com/AltGr/opam-bundle#opam21 to try it) that should work but it needs some polishing.

Also, this was not the initial question, but for another way of distributing binaries, I just wrote a guide on static linking and generation of portable executables.

3 Likes
7

Is the distributing static binaries thing what you are using for the opam executables?

I’ll try both methods (opam-bundle, plus a static executable compiled on Alpine Linux).
But, I guess many opam packages will not install under Alpine, because they don’t
have the same package offering as Debian; many conf-* packages may fail to install, I suspect).

8

More or less, yes, actually I found some refinements in the meantime and when writing the blogpost :slight_smile:

The conf-* packages define their depext field for many different distributions, and you can expect them to work pretty well with Alpine since it’s maybe the most used distro for CI; with the built-in depexts handling in opam 2.1 that should be quite transparent too.
This said, opam-bundle in the current state of its 2.1 PR will not have all the confirmation prompts I’d like it to have when running the OS package manager.

1 Like