[opam-devel] [RFC] OPAM files as *the* OCaml package metadata format

[Daniel Bünzli]

Le vendredi, 15 avril 2016 à 04:28, Louis Gesbert a écrit :
> As for the final version, it's hard to predict, but I'd say it should be ready by the summer.
Mmmh. I want to move on quicker I think. I'd rather improve the topkg tool later (which is different from topkg the library). Now that I thought a little bit more about it, the x-fields should in fact have little impact on the API except changing some default values. I still need to know the name of the standard file (change log, readme, etc.) in the description without using opam or opam-lib so that I can automatically mention them in the OPAM install file.
  

> The main problem may actually be that there is no separate opam package ?

I guess so.
  
> I see. There is not much required from opam then,  

Only a var-lib section in OPAM install files if we take Michael's suggestion. I opened  

https://github.com/ocaml/opam/issues/2517
  
> maybe just automatic  
> installation (or linking) of the opam files to a standard location.

No. It should be the package's duty to do so, so that the install procedure is uniform whether you operate in an opam managed context or not. Otherwise we'll have packages that work in a context and not in the other and resulting annoying package fixing noise.

> That might be more explicit indeed, but makes descr-file and opam-included
> descr further apart (both are still supported at the moment, with a logged  
> warning if both are present).

I'd still argue for it, simply warn by consulting two fields... It's a "natural" value you often want to access, for example to generate package listings. The less data massaging the easier, e.g. `opam query -f synopsis` vs `opam query -f descr | head -n 1` and you are now windows incompatible.
  
>  
> Sorry, I was speaking about the `x-*` fields in the package definition
> ("opam") files.

Ah, I don't think it should be the business of the OCaml OPAM repository maintainers to have a say about what these fields hold as long as they do not influence OPAM itself or are directly related to the resulting experience they expect from the repository (e.g. if some of the fields are used by build system link helpers).  

Best,  

Daniel