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