Simplifying 0install's solver with OCaml's functors | Hacker News Reader

Simplifying 0install's solver with OCaml's functors

roscidus.com

37 pointslpw259 comments

I have been very impressed by the blog posts, and I saw 0install in beta many years ago. It is interesting to me because it sounds like (from my novice view) that it was doing what Nix wanted to do, which is install software and its dependencies independently siloed and allow everything run AND to do it cross platform. You can tell by this guy's switch OCaml, getting hired for Ocaml work, and the scale of what he has done he is crazy and talented, but it seems 0install is still kind of obscure.

Beyond gourneau, is nayone using it and can say it is worth it? I am looking at available packages to see it is worth giving a go.

The list of publicly-known packages can be found on the default mirror site: http://roscidus.com/0mirror/

In general, though, if there's some package you want and you look for it there you're likely to be disappointed. 0install is probably more interesting to people wanting to publish software (and particularly, collections of related software).

Good use cases would be:

- Using it to build a package manager for a programming language (Rust would have been a good fit, I think, though like most languages they prefer to build their own language-specific system).

- Distributing applications for a desktop environment (the ROX desktop was the original motivation to create 0install).

- Managing plugins for a large application (Drupal, etc).

It might be best to think of it as a platform on which you can build a package manager or community.

Of course, people use it for individual applications too, but then you pay the cost of having to explain to your users what it is the first time. With a larger collection, the payoff is better.

I am a contributor, and I use it all the time. I publish a lot of my own stuff (mostly small utilities / libraries) at http://gfxmonk.net/dist/0install/index/, as well as a bunch of third-party software. Making distro-specific packages for all of these would be a stupid amount of effort - with a single zeroinstall feed I can run cross-platform code without having to package it N different times.

It is fairly easy to package / distribute portable code (e.g python, ruby, perl, js, etc). Stuff that requires compilation tends to be trickier, unfortunately (both to use and to distribute). Compiled software that is not relocatable (i.e hard codes paths) is sadly not possible to package in ZeroInstall.

It can use system packages (e.g apt, yum, etc) when available. So you can make a simple feed for your code that just depends on system versions of your dependencies, rather than having to "package the world". Of course, this only works on linux (and maybe OSX with fink / ports, but those tend to be less reliable than linux packages).

The big downside is of course that users don't generally know about ZeroInstall, and aren't likely to care why you think it's great. I generally recommend using ZeroInstall whenever I can in my own READMEs, but I have had little feedback on whether this has actually convinced anyone.

It has some definite upsides though, which is why I don't expect to stop using it myself regardless of general uptake:

- end users who aren't comfortable with terminals can use it just fine, yet it's as easy to publish as something like `pip` or `npm` packages.

- Since ZeroInstall feeds don't install anything globally, using zeroinstall dependencies during development means you never have to bother with tools like rvm, virtualenv, etc again.

- The savings that I personally get from having my own software & tools immediately available anywhere I go is already worth the effort of packaging it for ZeroInstall. E.g I have a "tim's custom vim" feed, with dependencies on all my vim plugins and configuration, and running it doesn't touch the host system's .vimrc or anything. That's pretty damn cool, even though it's only useful to me.

- I really like the notion that if you can _run_ some code, you can _modify_ that code. I despise the jump in most software between the "install & run" steps, and the "oh, you have to do these 10 manual and rather invasive steps to set up a development environment for this code". 0compile fixes this, for feeds that make use of it.

Ok, I hate you. I will look into 0install more seriously this time around, because you made a good pitch. Still, two questions:

- The 0install feed for your customized vim install, can you link to it?

- Out of curiosity, have you contributed to the Python and OCaml versions, or only one? If one, which?

UPDATE: For others interested, obviously your 0install feed what onerous to find, haha.

http://gfxmonk.net/dist/0install/index/

Great :D

Sounds like you already found my vim feed, but yeah, it's at http://gfxmonk.net/dist/0install/vim-custom.xml (it's not on that index page, because nobody else is likely to want it).

I've contributed to both the python & ocaml versions (and I made the logo :)). The ocaml version has not existed for all that long, I've only sent a few patches - I believe the porting itself was entirely done by Thomas, who's done great work.

A bit of a tangent, but I actually shipped 0install on a system I built a few years back. It was intended to be a way to help users manage plugins. 0install is a really fantastic idea. However, the lack of packages and community eventually made me regret that decision. If I had to do it over again today I would have used docker.

Do you feel docker and 0install fill the same space?

One thing struck me as odd reading this: he skips over the implementation of the Make functor, which is the interesting bit. But looking at [1], I realized it was a bit hairy. For a maybe more approachable example of a Make functor, you can have a look at [2] around line 1181: given a module with a type t and a comparator function, it creates a module for a set of elements of type t.

That said, it's a really nice set of posts, and they're the initial reason I started to get interested in the language.

1: https://github.com/0install/0install/blob/master/ocaml/zeroi...

2: https://github.com/janestreet/core_kernel/blob/master/lib/co...

Yes, and this hairiness is the main reason the abstraction is useful. If you want to add support for e.g. dependencies on source code, cross-compilation, multiple scopes, etc, you can now do so without looking at the hairy code at all, because the type signature tells you everything you need to know about it and is abstract enough to support what you want.

And if you do need to work on it, you don't need to think about the rest of the program at the same time.

e.g. because you want to make it less hairy ;-)

Reply on news.ycombinator.com