[opam-devel] Ideas from Node.js

[Sylvain Le Gall]

2013/10/12 Anil Madhavapeddy <anil at recoil.org>:
>
> On 11 Oct 2013, at 23:00, Sylvain Le Gall <sylvain+ocaml at le-gall.net> wrote:
>
>> Hello,
>>
>> This is something already somehow do-able with OASIS: just embed an
>> _oasis (more rfc822 than JSON) and use oasis2opam to convert the
>> _oasis to OPAM required files.
>>
>> http://oasis.forge.ocamlcore.org
>>
>> If OPAM dev would integrate a little more with OASIS (i.e. get rid of
>> oasis2opam to directly read data from _oasis distributed with upstream
>> package) and allow override using classic OPAM files, it will be super
>> easy to release OASIS package directly in OPAM.
>
> This has the same problem that Malcolm just explained -- you tie the
> metadata to some file *inside* the package, which requires distribution
> patches if you want to override it.
>
> What's wrong with oasis2opam that can't be fixed with a shell script
> wrapper `opam-mk-oasis-package` or something similar?
>

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).

Are my explanation clear?

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.

Regards
Sylvain