<p dir="ltr">But nix doesn't fix the diamond dependency problem, does it?  If library a depends on core 109.07 and b depends on 109.08, then an app that wants to link in both a and b is in some real trouble.</p>
<p dir="ltr">Or am I missing something?</p>
<div class="gmail_quote">On Feb 15, 2013 6:37 AM, "Malcolm Matalka" <<a href="mailto:mmatalka@gmail.com">mmatalka@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>I get around this in Nix with chroot and building OCAMLPATH on the fly. </p>
<div class="gmail_quote">On Feb 15, 2013 12:34 PM, "Anil Madhavapeddy" <<a href="mailto:anil@recoil.org" target="_blank">anil@recoil.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

OPAM has a strong dependency on ocamlfind at the moment, which doesn't<br>
support multiple library versions.  OPAM could be extended to support<br>
multiple installations (since the constraint model expresses it fine),<br>
but would need to understand more of the build process too.<br>
<br>
There are some steps towards this already, such as the `.install` files<br>
which automate binary installation/removal.  We were reluctant to put<br>
any more in the first version in the interests of getting something out.<br>
<br>
-anil<br>
<br>
On 15 Feb 2013, at 11:21, Malcolm Matalka <<a href="mailto:mmatalka@gmail.com" target="_blank">mmatalka@gmail.com</a>> wrote:<br>
<br>
> Right now, I think Core not being afraid to change frequently is good.<br>
> I'd rather have that than a stale API that kind of sucks.  And I'd hate<br>
> to have the public Core get out of synch with what Jane St uses<br>
> internally because it increases the overhead for you which decreases the<br>
> chance of timely releases.<br>
><br>
> Multiple versions has not been a problem for me since I convert opam<br>
> packages I'm interested in to Nix packages, and Nix handles multiple<br>
> versions of installed packages just fine.  It's probably too late in the<br>
> game for opam to have this style as well, I don't know anything about<br>
> opam's design, but it's worked pretty well in Nix for me.<br>
><br>
> Beyond that, I think good semantic versioning is probably key.  If the<br>
> majority of Core changes are backwards compatible (I have no idea if<br>
> this is the case) then installing the right package for a lot of the<br>
> apps probably isn't so bad.<br>
><br>
> /Malcolm<br>
><br>
> Yaron Minsky <<a href="mailto:yminsky@janestreet.com" target="_blank">yminsky@janestreet.com</a>> writes:<br>
><br>
>> Right now, the Core suite of libraries changes a lot --- we have a new<br>
>> release of everything every week.  The changes on a given week are<br>
>> small, but there are always changes.<br>
>><br>
>> I can imagine this being something of a problem for OPAM.  If packages<br>
>> specify specific revisions of the Core suite, then we're going to have<br>
>> a massive version mismatch problem, where no two libraries can agree<br>
>> on the version of Core that they need.<br>
>><br>
>> I have no obvious ideas as to how to solve this.  Does anyone else<br>
>> have ideas?  Should we simply encourage packagers to specify a<br>
>> lower-bound constraint on the Core libraries?<br>
>><br>
>> y<br>
>> _______________________________________________<br>
>> Platform mailing list<br>
>> <a href="mailto:Platform@lists.ocaml.org" target="_blank">Platform@lists.ocaml.org</a><br>
>> <a href="http://lists.ocaml.org/listinfo/platform" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
> _______________________________________________<br>
> Platform mailing list<br>
> <a href="mailto:Platform@lists.ocaml.org" target="_blank">Platform@lists.ocaml.org</a><br>
> <a href="http://lists.ocaml.org/listinfo/platform" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
><br>
<br>
</blockquote></div>
</blockquote></div>