Re: [Caml-list] opam and godi

["Török Edwin" <edwin+ml-ocaml@etorok.net>]

On 07/21/2013 05:43 PM, Yaron Minsky wrote:
> While I appreciate the work that Gerd has done on GODI, I do think
> that OPAM is a significant improvement over GODI.

I thought I'd share why and how I started using OPAM.

I have used GODI briefly when I had to install some application on RHEL, which had some old version of the OCaml compiler at the time, and missing most of the libraries I needed.
GODI was very smooth to use for that purpose, and I'm glad that someone dedicated time to writing and maintaining it.

My main system is Debian though, and I was quite happy with the OCaml packages provided by the distribution, so I didn't have a reason to use GODI (or another source-based package manager) on Debian.
After OCaml 4.00 got released I eventually needed a source-based package manager, and when OPAM was available I gave it a try. It was fairly simple to use and worked well (except some small issues with upgrades ocasionally), and it is the main package manager I use for OCaml now.

> 
> From an end-user-experience perspective, I've found OPAM to be
> considerably smoother than GODI.  In addition to having what I
> consider to be a better user interface,

opam's simplistic interface is closer to apt-get, which I use and like.
GODI's ncurses-like interface is more like aptitude's curses-interface ... which I don't use.
It also has a command-line interface, which I haven't tried (the docs place little emphasis on it).

So perhaps the less-advanced interface of opam wins exactly because of that.
Or maybe it is because GODI already existed at the time I started learning OCaml, and OPAM is the new tool for me that came much later, and I like it only because I used it more recently.

There is more to OPAM though, 'opam switch' is definitely a useful feature, as is the ability to use the system's OCaml compiler (I may be wrong here, does GODI support that?).

Having said that I would've preferred if OPAM and GODI worked together rather than having a completely new project.
In the end I think what would be best is if OASIS could be automatically converted to OPAM, GODI, DEB and RPM packages, and then upstream projects would only need to worry about supplying one correct _oasis file, and OPAM/GODI could use that directly, so that all build/depedency etc. fixes eventually end up in all repositories.
And of course the conversion shouldn't be one-time only, whenever _oasis is updated the changes should propagate, perhaps with some small addons _oasis.debian, _oasis.opam, etc. for things that cannot be expressed in OASIS directly (or which doesn't make sense to have in _oasis, like name of downstream maintainers).
Packagers should prefer to update these files, instead of their distribution-specific ones, and have the distro-specific build descriptions automatically generated from this.

I'm aware that OASIS is not perfect either (there was a discussion earlier about installing docs), but I think that improving it (and the conversion tools) would eventually get us a simple unified build/package description and then library/application authors and end-users shouldn't care what package manager they use: they'd get a similar quality experience. And whenever a bug is discovered by the user of one package manager, the fix is applied to all.

I'm aware that oasis2deb, oasis2opam exist, does oasis2godi and oasis2rpm exist? How does OASIS-DB fit into this picture?
There is of course the question what to do about packages that do not provide an _oasis file, maybe a start would be opam2oasis (and godi2oasis?) that would provide a dummy _oasis file that just uses the custom Makefiles of the package, but provide all the metadata that the package does.

> upgrading of packages in OPAM
> has been very smooth overall.  I found upgrades in GODI to be pretty
> tricky, with many upgrades ending in failure for one reason or
> another.

I've had OPAM upgrades fail due to bugs in packages / missing system dependencies a few times,
and there is a bug open about support for rollbacks, so it is not as smooth as "apt-get" yet.
I haven't used GODI long enough to be able to compare it with OPAM on this regard.


>  I suspect this has something to do with the system for
> handling of dependencies in OPAM, which has taken quite a bit of work
> to get right from what I understand.
> 
> In addition, the ability to easily handle multiple compilers in OPAM
> is also a big win, from my perspective.  I think it makes it much
> easier to try out and give feedback on upcoming compiler versions,
> which is good for the community as a whole.  (Plus, trying out
> bleeding-edge compiler patches is fun...)

Agreed.

Best regards,
--Edwin