[opam-devel] re. local roots/switches: Documentation for the "nix-style" new-build approach in Cabal

Gabriel Scherer gabriel.scherer at gmail.com
Fri Sep 2 13:17:37 BST 2016


One aspect of the tool exhibited in this document that I found
interesting is that the design and user experience is not concentrated
on a "local root to develop a new package" workflow, but "local root
to develop a set of related packages together" workflow :
multi-package. There is a conceptual difference between the "local
packages" in this set and the "external packages" that are expected to
remain stable during development (in general).

To my knowledge there is no such established multi-package concept in
related OCaml tooling these days, and there are cases where we don't
do very well on this workflow. For example, Thomas Gazagnaire and
Jérémie Dimino have ocamlbuild plugins to rebuild the project when
ocamlfind dependencies changed that are very important in this
workflow, but currently not part of the default tool (
https://github.com/ocaml/ocamlbuild/issues/91 ). It mostly affect
aspects of the user experience that are outside of opam's domain, but
I think it may still be a relevant distinction for opam.

On Fri, Sep 2, 2016 at 2:08 PM, Gabriel Scherer
<gabriel.scherer at gmail.com> wrote:
> Hi opam-devel,
>
> You may be interested in this document being elaborated by Edward Yang
> as part of his work "cabal new-build" that is described as a
> "nix-style local build" for cabal (a core Haskell tool that is on the
> crossroad between opam and oasis and ocamlbuild, and as you could
> guess has unsatisfied users on all three of these fronts). It could be
> interesting and inspirational with respect to the discussion on
> workflows for local roots or local switches in opam.
>
>   Cabal User Guide: Nix-style local builds
>   http://ezyang.com/nix-local-build.html
>
> (Other tools of interest from other communities would be Haskell's
> "stack" and Rust's "cargo", but they differ and are interesting in
> many broader, less well-defined aspects of the user experience, and I
> have no personal experience with them.)


More information about the opam-devel mailing list