[opam-devel] Ideas from Node.js

Anil Madhavapeddy anil at recoil.org
Sat Oct 12 11:07:17 BST 2013

On 12 Oct 2013, at 11:01, Sylvain Le Gall <sylvain+ocaml at le-gall.net> wrote:
> I agree on the need of separation of package metadata (because they
> often need patching for distribution) with the rest of the package. As
> said, I think the current design is fine.
> What would be nice is to have this opam-mk-oasis-package integrated
> inside OPAM worflow. This would allow to remove one step when
> publishing package on OPAM.
> Here is the process I would like to see:
> - enter a the URL of your tarball in a box on opam.ocamlpro.com
> - download the tarball
> - if the tarball/_oasis is fine, just create all required files using
> oasis2opam and publish opam/packages/X.V/{opam,url,descr} (no install
> of oasis2opam, no github fork, no pull request on client side, maybe
> some on server side)
> - if later you have to patch files, patch directly the generated
> opam|url|descr (normal process)
> Advantage:
> - you can bootstrap package metadata from upstream description (thanks
> to oasis2opam)
> - the full process is very close to a normal OPAM publishing workflow,
> changes needed to OPAM can be almost 0
> The goal is to have just a single step to upload an OPAM package from
> upstream sources in best case, if the _oasis coming along the upstream
> package is fine.
> Let say the issue is more about integration than design (I think we
> have all piece to create this process and now the question is: does it
> make sense to integrate it inside OPAM directly).

To reiterate, none of this requires any changes in OPAM. You can just
create a wrapper script that does all this (including the GitHub workflow
you propose).  Note that the workflow will still require a clear client
pull request, since that's what triggers off the continuous integration
tests.  OPAM already has an extension mechanism similar to git's, where
it executes an `opam unknown` command by running the `opam-unknown` binary
with the subcommand stripped from argv.

> Side note, this process is inspired by the one I have on OASIS-DB (and
> also by the missing feature I have there). If OPAM upstream agree on
> this plan, I can do a demo on OASIS-DB before having it running on
> http://opam.ocamlpro.com. It will take a little bit of time, because I
> am an OPAM dev beginner.

I think that the web integration makes everything more complicated.  Just
a shell script is fine to start with, and then web integration.


More information about the opam-devel mailing list