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



_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel

Reply via email to