[opam-devel] 'provides' field design proposal

[Thomas Gazagnaire]

> * checking concrete dependencies: not sure how that would be covered by 'provides', as it is the conjunction of several packages that provides the new one (cohttp + lwt => cohttp-lwt). It seems closer to the 'features' stuff, but you can't _depend_ on a feature with the current design (restricting features definitions to package formulas may make it possible though; I'll think about it)...
>  Another possibility, maybe (but interaction with cudf would need to be carefully studied, because we are getting out of what is supported), would be to have additional formulas on 'provides':
>  cohttp/ provides: [ "cohttp-lwt" { lwt } ]
>  In terms of rewriting it doesn't seem much more difficult, virtual package cohttp-lwt would include ("cohttp" & "lwt") in its depends disjunction instead of just "cohttp". Anyway, we can easily leave that part for later.

Not sure I understand that part. Would it be simpler to always require that "provides" contains the name(s) of concrete package(s)? Supporting "virtual packages" means that we have 2 ways to do the same things: depots and provides. Which means it is harder to explain to the user what to use when.

I think the goal of "provides" should be "just" a simple way to provide slightly patched opam packages without requiring hackish pining, not a way to expose in the "provides" all the modules/implementations provided by an opam package (although it could be a good idea too, but I think should be kept out of the scope of that proposal).

Thomas

> 
> * new question: if I have several packages providing Foo, should I recompile a package depending on Foo whenever one of them changes ? I'd say yes...
> 
> * Location of design documents: not sure at all this is best, because versionning of the design document (at least during the design phase) doesn't need to be synchronized with the source, but it has its advantages, and I don't like github's wikis much. Seemed more practical for something in-depth than just an issue. Do you suggest another option ? Adding headers is a good idea.
> 
> Cheers!
> Louis
> 
>> - Anil Madhavapeddy, 06/01/2015 15:39 -
>> Looks great, Louis!  My immediate thoughts:
>> 
>> - This does have the potential to complicating pinning quite a lot, which
>> needs to be balanced against the better upgrade messages.  Do you think 
>> this will need a package selection priority the way that apt-pinning in
>> Debian works (e.g. so that ocaml-tls can be selected ahead of openssl-tls
>> for the TLS package).
>> 
>> - The forking and providing replacements would be really useful for Mirage,
>> where we're having an active discussion about how to provide Xen-specific
>> versions of certain packages such as Zarith.  Thomas (with any surname),
>> opinions on this?
>> 
>> - How much damage will this do to the internal solver heuristics?
>> 
>> -anil
>> 
>>> On 5 Jan 2015, at 08:36, Louis Gesbert <louis.gesbert at ocamlpro.com> wrote:
>>> 
>>> Hi all, and happy new year !
>>> 
>>> I just added to opam a design proposal to open discussion on the implementation of the 'provides' field and its use-cases.
>>> 
>>> It's at https://github.com/ocaml/opam/blob/master/doc/design/provides.md
>>> 
>>> Cheers,
>>> Louis
>>> _______________________________________________
>>> opam-devel mailing list
>>> opam-devel at lists.ocaml.org
>>> http://lists.ocaml.org/listinfo/opam-devel
>>> 
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel