Document opam-lib use-cases before OPAM2

[avsm]

One of OPAM2's headline features is a comprehensive rewrite of the API to make it easier to consume (online doc). This is a good excuse to list the current users of opam-lib and to ensure that they are ported:

In OPAM, we have:

• mirror 0.0.1: Mirror upstream OPAM package distribution files
• odig 0.0.1: Mine installed OCaml packages
• publish 0.3.:2 A tool to ease contributions to opam repositories.
• opam-query 1.2: A tool to query opam files from shell scripts
• opamfu 0.1.3: Functions over OPAM Universes
• topkg-care 0.7.9: The transitory OCaml software packager
• opam2web: A tool to generate a website from an OPAM repository

Unreleased or dev users:

• twiopam dev: This Week in OPAM email scripts to generate changelogs in packages
• opam-builder dev: generates the webpage at http://opam.ocamlpro.com/builder/html/report-last.html

There are also several CI scripts that depend on the CLI output of OPAM, so we need to ensure that they are compatible with OPAM2 or can discriminate based on version:

• ocaml-ci-scripts: contains Travis CI and Appveyor scripts
• dockerfile: contains OPAM1 and OPAM2-specific logic to make the container images on Hub:opam and Hub:opam-dev work smoothly.

This issue is to track:

• the list of other libraries I may have missed. If you are aware of some software, please comment and I will update the issue
• to close the issue, I'd like a webpage on opam.ocaml.org that lists some of the popular tools and plugins accrued here so that they are easier to find.

[samoht]

• opam2web uses it to generate https://opam.ocaml.org

[avsm]

Doh! Missed the obvious one -- editing comment now.

[ivg]

In bap we don't really rely too much on the opam interface. The only call to opam that is made is opam lint, and we do not rely on the output, just on the returned code. Everything else just relies on the presence of files, such as opam and url, as well as the presence of version, url and checksum fields.

Basically, this is the function, that we use to automate the release, it is pretty stupid:

# ``release_package pkg old new url md5`` release a pkg by copying
#  existing description and bumping version and archive url.
release_package() {
    pkg=$1
    old=$2
    new=$3
    url=$4
    md5=$5
    oldpath=packages/$pkg/$pkg.$old
    newpath=packages/$pkg/$pkg.$new

    echo "releasing $pkg from $oldpath to $newpath..."
    mkdir -p $newpath
    cp -r $oldpath/* $newpath
    if [ $# -gt 3 ]; then
    cat > $newpath/url <<EOF
archive: "$url"
checksum: "$md5"
EOF
    fi
    sed -i "s/^version:.*/version: \"$new\"/" $newpath/opam
    git add $newpath
}

Since, we're planning to release every month, we will eventually develop a better automation, as using the above procedure is rather tedious and error prone.

[AltGr]

I'd add:

• OWS, that generates the page at http://ows.irill.org/latest/today/. It is based on the new version of dose and a patched opam 1.3 (I should forward-port the patches anyway to benefit from the new dose)
• Camelus -- but that one is already on an earlier 2.0 version, so almost no work should be needed

Also, some remarks on the already cited ones:

• opam-query's functionality has mostly been backported to opam, although the syntax may be less lightweight: opam show --file ./opam -f 'maintainer:'. opam doesn't have the github archive magic though.

[dbuenzli]

Both odig and topkg-care have migrated to opam-format.

[timbertson]

👋 https://github.com/timbertson/opam2nix

I hope to port to opam 2 sometime, but haven't found the time to investigate this yet. It's not a trivial integration, mostly because I need to parse a bunch of stuff from opam files and understand the dependency formulas. But hopefully that core part hasn't changed too dramatically.