I’ll offer my two cents. One overriding issue of package management is dependency resolution.
In the case of ruby, multiple versions of a gem happily co-exist globally with applications loading compatible subsets based on its Gemfile.lock, by virtue of package dependency resolver, bundler. This differs from node's npm and yarn, which install local copies (often multiple) of package dependencies under an application’s root directory. In this case, I’m not aware of a benefit to installing packages globally, unless those packages install commands like npm and yarn themselves. With Haskell, all bets are off. Installing packages globally creates problems that neither of Haskell’s package managers cabal(1) nor stack(1) seem capable of dealing with. For example, I recently offered a recipe for installing pandoc(1) on older Intel systems. But subsequently, I found that I was unable to update to most the current version. I had to go back to Pandoc version 2.0.6 in order to build on my system under ideal conditions, i.e., installation of current Haskell Platform. While I’m not familiar with Ocaml, from the website, opam appears to uses Debian CUDF dependency resolver <http://www.mancoosi.org/cudf/>. Consequently, I would expect that Ocaml can handle multiple globally installed packages. There is a libCUDF to help with parsing CUDF files, so that might be worth looking at if you wanted to build an opam2port utility. -AM > On Apr 18, 2018, at 11:35 AM, Clemens Lang <[email protected]> wrote: > > Hi, > > ----- On 18 Apr, 2018, at 15:20, Perry E. Metzger [email protected] wrote: > >> Maybe I should ask this a bit differently. Are there other precedents >> for using a "foreign" packaging or build system and tricking it into >> building stuff for macports that I could study and possibly steal >> pieces of? > > You can take a look at the haskell portgroup, which uses cabal to build > and destroot things. The rust portgroup that uses cargo might also be > an interesting example. > > -- > Clemens Lang
