<div dir="ltr">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].<div><br></div><div>[1] <a href="https://github.com/solvuu/biopam">https://github.com/solvuu/biopam</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 10:30 AM, Thomas Gazagnaire <span dir="ltr"><<a href="mailto:thomas@gazagnaire.org" target="_blank">thomas@gazagnaire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Louis.<br>
<br>
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:<br>
<br>
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<br>
<br>
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.<br>
<br>
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.<br>
<br>
And last big item, that I haven't seen in your list: windows support: is this still on the map?<br>
<br>
Thomas<br>
<div><div class="h5"><br>
> On 18 Dec 2015, at 08:47, Louis Gesbert <<a href="mailto:louis.gesbert@ocamlpro.com">louis.gesbert@ocamlpro.com</a>> wrote:<br>
><br>
> This is a summary of what's going on for 1.3, for all those who were wondering.<br>
> This is not complete, and I may have forgotten stuff, don't hesitate to complete<br>
> and comment.<br>
><br>
> I think a more redacted version of this would have its place on the platform<br>
> blog, to show there is activity.<br>
><br>
> Note that I've also been busy helping out on the flambda compiler patch, which<br>
> explains that things have been a bit slower on opam lately, but I am getting<br>
> back on it full-time soon.<br>
><br>
><br>
><br>
> # Ongoing changes for 1.3<br>
><br>
> Lots has been going on, signature of the repository was the main goal for this<br>
> release but it was then decided to prioritise some architectural changes and<br>
> improvements and add signature on top of that for the release just after. So I<br>
> feel there is a need to clarify all that's going on and what to expect for<br>
> 1.3.0.<br>
><br>
> - Simplification of the ~/.opam architecture, store switch state in a single<br>
>  file (done, but more changes pending)<br>
><br>
> - Refactoring of file handling, for better error reporting, more reliable code<br>
>  and ease to extend (done)<br>
><br>
> - Much cleaner and flexible URL handling (including VC targets and specific<br>
>  transports) (done)<br>
><br>
> - Refactoring of OpamState, lots of simplification on state loading, pinned<br>
>  package handling. This should make it much easier to understand and maintain,<br>
>  and also much more efficient (ongoing)<br>
><br>
> - Compilers as packages and disappearance of the .comp files, through making the<br>
>  opam files much more generic. In practice, switch creation and compiler<br>
>  installation are now internally treated as two different operations (ongoing,<br>
>  most of it done but lacks a proper interface at the moment)<br>
><br>
> - Tracking of package installed files and reliable automatic removal (planned,<br>
>  but the hard part is done)<br>
><br>
> - Setup of package configuration variables (planned)<br>
><br>
> ### Package definitions<br>
><br>
> - Inclusion of url and descr in the opam file format, to describe a package with<br>
>  a single file (done)<br>
><br>
> - Better definition of package variables, self-references (done)<br>
><br>
> - Support for "dev" dependencies (done)<br>
><br>
> - Allow packages to define environment variables, possibly depending on other<br>
>  variables or features (`setenv:` field) (done)<br>
><br>
> - Allow fields for use by external tools: `x-fieldname:` (done)<br>
><br>
> - Conflicts now consistently treated as disjunction (i.e. a formula that must<br>
>  not be true) (done)<br>
><br>
> - Add `extra-sources:` for packages needing more than a single archive (e.g.<br>
>  compiler packages) (planned)<br>
><br>
> - Allow to quote strings with pythonesque `"""` delimiters, for easier<br>
>  integration of package descriptions (done)<br>
><br>
> - Possibility to depend on the hash on an arbitrary file on the system and<br>
>  trigger reinstallation, e.g. to detect an updated system compiler (ongoing)<br>
><br>
> - New "canonical" and "format-preserving" printers, resp. for signing and<br>
>  batch-editing files (done)<br>
><br>
> ### Other, smaller changes<br>
><br>
> - Ability to override switch default dirs using<br>
>  switch/config/global-config.config. `opam config set` command (done)<br>
><br>
> - Support (and doc) for many different external solvers besides aspcud (done)<br>
><br>
> - Json output including command logs that could be usedd to browse the status<br>
>  (done)<br>
><br>
> - More flexibility for install, reinstall, upgrade commands when the package<br>
>  isn't in the expected state (already installed or not installed) (done)<br>
><br>
> There are also plans on easing cross-compilation and allowing operations across<br>
> switches which are well underway (in large part thanks to Pietro Abate's<br>
> efforts), but these are intended for the next minor release (e.g. 1.3.1).<br>
</div></div>> _______________________________________________<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>
<br>
_______________________________________________<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>
</blockquote></div><br></div>