[opam-devel] OPAM Roadmap -- what next ?

[Peter Zotov]

On 2014-12-21 16:37, Thomas Leonard wrote:
> On 21 December 2014 at 13:26, Peter Zotov <whitequark at whitequark.org> 
> wrote:
>> On 2014-12-21 16:19, Daniel Bünzli wrote:
>>> 
>>> Le dimanche, 21 décembre 2014 à 13:43, Peter Zotov a écrit :
>>> 
>>>> Imagine four packages installed:
>>>> * B.1
>>>> * B.2
>>>> * A.1 depends: B<2
>>>> * A.2 depends B>=2
>>>> 
>>>> Now if you request A.1, the wrong version of B will get pulled in.
>>> 
>>> 
>>> Request through what ? I think your scenario is underspecified. If
>>> A.1's META file specifies that it requires B.1 then B.1 will be 
>>> pulled
>>> in.
>> 
>> 
>> Through ocamlfind, of course, there's nothing else now.
>> 
>> Sure. But note that ocamlfind explicitly refuses to deal with 
>> versioning
>> constraints; it's even in the manual. So the dependencies of neither
>> A.1 nor A.2 are not expressible in META.
>> 
>> Additionally, this requires more work from package maintainers, and
>> I can't imagine how to convince them to do it. (I do not think
>> it is possible to automatically infer those from opam fields.)
> 
> If the information can't be inferred from opam fields, then how can
> things even work now? Somehow, there must be valid and invalid
> combinations, and it must be possible to know what they are. e.g. a
> valid (per-build) combination in a world of parallel installs is any
> combination that could be installed now.

Actually you're right. It will be possible to use the `findlib` files
in opam repository to infer the mapping.

> 
> FWIW, 0install has always done parallel installs and it hasn't been a
> problem, except that you always have to start your build from a
> 0install-aware tool (or an environment created by one). The problem is
> mainly that people want to continue with their current habbits (e.g.
> unpack source archive and run make). Some change in tools or habits is
> needed.

I still don't see a reason to have multiple versions installed at once
that would justify the migration cost.

The use case with JS/CSS libraries can easily be handled by mangling
the name of the package and/or using the "provides" feature.

-- 
Peter Zotov