Re: [Caml-list] OPAM conventions

[Anil Madhavapeddy <anil@recoil.org>]

On 12 Dec 2012, at 14:47, Dario Teixeira <darioteixeira@yahoo.com> wrote:

> Hi,
> 
> I've been looking at the OPAM package database -- trying to determine overall
> conventions and best practices -- and I came across some inconsistencies.
> Though in most cases these are purely cosmetical, I reckon that nevertheless
> we could all benefit if some standardisation is agreed upon on.  Examples:
> 
> 1) Package naming
> 
>    For some values of "foo", OPAM's package name for project "ocaml-foo"
>    is also "ocaml-foo", whereas for others is simply "foo".  This is an
>    ackowledged issue by OPAM developers:
>    https://github.com/OCamlPro/opam-repository/issues/163
> 
>   In my mind, there are only two sensible policies for naming OPAM packages:
> 
>   a) OPAM packages should preserve the name of the original project.
>      Thus, if the project is named "ocaml-foo", the OPAM package will
>      also be "ocaml-foo".
> 
>   b) OPAM packages should have the same name as the findlib entry.
>      If project "ocaml-foo" registers itself in findlib with name
>      "foo", then "foo" should also be the name of the OPAM package.
> 
>    Good arguments can be made for and against each option.  Though this
>    is largely a bike-shedding issue, I think the community should make
>    a decision sooner rather than later.

I generally don't like typing too much, and so prefer the shorter name.
But converting packages names isn't really a big deal and can be done
mechanically, so it's more important to build up the database first.

> 
> 2) Invoking executables
> 
>    To invoke, say, a configure script, some packages will nonchalantly
>    just declare ["./configure"] whereas others will ask the shell to
>    do it: ["sh" "configure"].  While either should work in any Unix
>    system, should one be preferred for compatibility with more exotic
>    systems?

If the upstream package has the configure script marked as executable,
then ./configure should be fine.  Some don't (this used to be a bigger
problem when some VCS's couldn't track file modes, but isn't an issue
in modern systems).

> 3) Package removal
> 
>    For most values of "foo", package "foo" will just declare ["ocamlfind"
>    "remove" "foo"].  However, this approach seems a bit brittle to me.
>    If the Makefile supports "uninstall" (which is the usually the case
>    for OASIS packages), then I reckon that ["%{make}%" "uninstall"]
>    should be preferred.
> 
>    Having said that, it seems that ["%{make}%" "uninstall"] is currently
>    not working (OPAM tries to download the package de novo upon removal!).
>    Is this a bug or a feature?

The issue with removal is that the package needs to be available to run
make uninstall, hence the download.

In the longer term, we've discussed letting the OPAM package declare
which ocamlfind packages it installs, and having those automatically
handled (i.e. the install phase asserts that the package exists as a
post-condition, and the uninstall removes it and checks it's gone).

But that's all post-OPAM-1.0! Basics first.

> 4) Findlib dependency
> 
>    Most packages do declare a dependency on ocamlfind.  However, this is
>    not universal, even for packages that do register themselves with findlib.
>    What should be the standard here: always declare a dependency, or omit
>    it altogether since it is implied?

If something uses ocamlfind and doesn't declare it explicitly, it's a bug.
The continuous build system catches most of these, and in practise it doesn't
matter as a dependent package will pull it in, but it's best to be explicit
about it.

-anil