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