Thanks for the info. On Fri, Dec 18, 2015 at 8:42 PM, Louis Gesbert <[email protected]> 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 > [email protected] > http://lists.ocaml.org/listinfo/opam-devel >
_______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
