1. 2

    OCaml could do with a CI site. Circle and travis can do it but it requires a hell of a lot more effort than explicitly supported languages. Inria has a CI site, iirc https://ci.inria.fr/ but when last I looked was for Inria people only.

    1. 3

      For upstream repositories, people normally seem to use Travis or AppVeyor (for Windows), using the scripts at https://github.com/ocaml/ocaml-ci-scripts.

      Another option is to provide a Dockerfile and then configure Travis to build that (e.g. https://github.com/mirage/capnp-rpc/blob/master/.travis.yml). That also means you can test the build locally easily and get the same result as the CI.

      For opam-repository, there are various CIs, e.g. http://check.ocamllabs.io/ shows the status of every version of every package in the repository against each version of the compiler.

    1. 5

      As the original author of the older LazyFS system mentioned in the article, it’s very interesting to see this. I’d like to say some things about why 0install moved away from it.

      The first problem was that, as a Linux kernel module, it broke every time a new kernel came out. This was before Linux had FUSE, of course. Asking users to install a kernel module wasn’t a great first-use experience…

      One thing I really liked about it was that it only downloaded the parts of the application you needed. For example, an application could ship with translations for many languages, but it would only cache the one(s) you used. And if you provided a big .dbg file with debug symbols, it would download that automatically if you tried to debug it with gdb, but at no cost to users who never used the debugger on it.

      Dealing with multiple versions was a bit of a problem, though. Like this AppFS, we provided every version of each package, with a latest symlink so you could run the current one easily. That works quite well, but it’s a problem if you want to run a program using an older version of a library, for example.

      In the end, I wrote a front-end that would read the metadata for each package, use a SAT solver to decide which library versions to use, set appropriate environment variables, and then launch the application.

      But once you have that, the user never sees the underlying virtual filesystem, and so you can simplify the whole system by removing it. So in modern versions of 0install the solver downloads regular archive files and unpacks each one in a unique directory on your regular file-system.

      That means you don’t need any system-wide set up (e.g. editing fstab, creating mount-points, or running system daemons to download things and report download progress). The only shared component in the current version is an (optional, and disabled by default) helper that allows multiple users to share downloads (but not the metadata; they must each discover the correct hash for themselves).

      Finally, getting rid of the virtual file system means that you can reuse a project’s regular archives, without requiring them to host anything special. It just requires someone to host the metadata file pointing to the archives, and that can be on a separate server if the upstream project isn’t interested (most aren’t, it turns out).