[ocaml-platform] Does Core change too often?

[Malcolm Matalka]

My Nix setup is a huge hack right now, but! here is my current public
fork of nixpkgs with an OLD version of opam + Core 108.07.01:

https://github.com/orbitz/nixpkgs/commit/fd598f1b55c94b4d466ac5ddffb304136bdc433e

The only interesting change is I had to patch Async because its build
script requires /bin/bash and /bin/mkdir. And the build failure for
Async is pretty awesome btw :)

(I'm not 100% sure that the above branch works on Nix since I have some
local changes that have been sitting around for awhile, but it gives the
gist.  If more complete, working versions, are interested to anyone I
can put the effort in to give a more complete demonstration)

I also have these cheap scripts I use to create my environment when
playing locally.  This should really be done as an eval like opam's
config but right now I do something like 'ocaml_run.sh make'.  Or
ocaml.sh to get the REPL.  This plays fine with opam (for me) since my
script is additive to the environment.

https://github.com/orbitz/ocaml_wrapper

@yaron - Correct, AFAIK this does not some diamond dep problem.  Based
on what Anil said I guess ocamlfind needs to be modified for that.  Or
the ability for libraries to be built with their deps linked in already.

/Malcolm

Anil Madhavapeddy <anil at recoil.org> writes:

> 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
>> >
>>