[opam-devel] opam 1.3 status

[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].

[1] https://github.com/solvuu/biopam


On Fri, Dec 18, 2015 at 10:30 AM, Thomas Gazagnaire <thomas at gazagnaire.org>
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 <louis.gesbert at ocamlpro.com>
> 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
> > opam-devel at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/opam-devel
>
> _______________________________________________
> 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/20151218/4c09c103/attachment.html>