[ocaml-platform] Does Core change too often?

[Anil Madhavapeddy]

Right, but the opportunities for re-using previously compiled libraries
are limited, because of the exact-version requirements.  Having multiple
OPAM switches per set of constraints would be almost as good, if much
more burdensome from a command-line perspective.

Do you have your Nix setup available anywhere? I'd definitely like to
have a play with it.

-anil

On 15 Feb 2013, at 11:37, Malcolm Matalka <mmatalka at gmail.com> wrote:

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