[opam-devel] opam 1.3 status

[Ashish Agarwal]

Thanks for the info.

On Fri, Dec 18, 2015 at 8:42 PM, Louis Gesbert <louis.gesbert at ocamlpro.com>
wrote:

> > Hi Louis.
> >
> > all of this sounds very good. I'd just like to report 3 more features
> that
> > various people have told me about this last months:
> >
> > 1/ `opam bundle`: it seems that a few existing projects don't want to
> tell
> > their users to install OCaml and opam. They just want a stand-alone
> tarball
> > that you can decompress and run `configure && make && make install`.
> There
> > are already some patches from @ygrek doing this, that would be very cool
> to
> > integrate the tool upstream
>
> Ah, indeed; these patches should be made easier by the reorganised
> opam-lib (I
> remember there were issues with e.g. OpamArg). I'll see with @ygrek once
> the
> current refactoring is done.
>
> > 2/ local switch/root. few people reported that they would like to use a
> > per-project opam root. This could be done easily by making the CLI check
> > for a `.opam` directory in parent directories. Or it could work with a
> > local config switch file (now that we have only one config file per
> > switch), stored in the repository.
>
> Why not, this sounds like a very easy one, at least with the first option
> --
> are there cases where this might get confusing ? The second one would allow
> sharing of repositories and `opam update` across "per-project switches", it
> boils down to "allow creating a switch with the prefix I supply" --
> something
> that I intended to add already, the `opam switch` interface needing to be
> rewritten anyway, since compilers turned into packages -- and some magic to
> automatically choose "current switch" based on PWD.
>
> However, this will only work for opam commands, and you still need to `eval
> $(opam config env)`, which really isn't a huge benefit compared to `eval
> $(opam config env --root/--switch xxx)` that you need without a specific
> feature.
>
> I think the best answer to these use-cases is clearly opam-manager [1],
> which
> was designed for this purpose: it can dynamically choose opam root and
> switch
> based on `.opam-switch` files found in ancestors of PWD, and more
> importantly,
> installs dispatchers for binaries that make them transparent -- without
> need
> for `config env`.
>
> [1]: https://github.com/OCamlPro/opam-manager
>
> > 3/ local remotes. Currently the remote are per-switch which make them a
> bit
> > annoying when you have a repo with dev packages. Currently it's easier to
> > share a list of pins that a remote. So maybe extend `opam pin` to allow
> to
> > take file of packages to pin -- actually it could already work with `opam
> > switch import`, so maybe it's just a matter of documentation.
>
> That's on my list too, but I delayed it until I finish refactoring
> OpamState
> -- it's tempting to change everything at once, but often a bad idea. I'm
> not
> sure it will make it for 1.3 though, although, since it will require yet
> another format change to ~/.opam, it may be better to have all these
> changes
> at once. In my new version repository state is completely decoupled from
> switch state, so the work will mostly be on how to define the repository
> state
> in the ~/.opam layout.
>
> > And last big item, that I haven't seen in your list: windows support: is
> > this still on the map?
>
> Yes. I consider it a parallel branch of work, so it may not be synchronised
> with 1.3, but effort is being put into this too.
>
> > - Ashish Agarwal -
> > Hi. Thanks for this nice summary and ongoing work. Is there any support
> > planned for installing binaries? What is needed is a way to specify a
> > different tarball depending on the detected architecture. I know some
> > people want this for OCaml packages, but actually I'm interested in it
> for
> > our non-OCaml biopam repo [1].
>
> I did not put this on the list, but have been thinking about it for a
> while.
> Once we have tracking of packages' files, extracting that info to generate
> binary packages, or even a full opam repository of binary packages, would
> be
> easy. There are many dark corners though, that may not be a problem for
> biocaml:
> - optional dependencies: you need to choose whether you want them before
> generating the binaries, obviously
> - ocaml is not relocatable, which is a big issue, although we have
> proposed a
> compiler patch a while ago and have some hacks available [2]
> - there are actually different approaches available, depending on whether
> you
> just want to cache builds, you want to distribute a bundle, or you want a
> real
> binary repository
> - local setup, external dependencies, etc.
>
> But some stuff on this front is to be expected too!
>
> [2] https://github.com/OCamlPro/ocp-reloc
>
>
> Hope this clarifies things!
>
> Best,
> Louis Gesbert, OCamlPro
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20151219/525bc090/attachment.html>