On 2014-12-21 16:37, Thomas Leonard wrote:
On 21 December 2014 at 13:26, Peter Zotov <[email protected]>
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
_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel
