1. 19
  1.  

  2. 2

    currently supports packages hosted on GitHub and GitLab.

    Locking into git is a bad idea… but locking it into GitHub and GitLab only is even worse! I can’t see why namespacing should have anything to do with repo URLs, and why it must not be possible to self-host packages. OPAM supports multiple URL schemas including git, mercurial, darcs, and HTTP.

    Also, I wonder if Poly/ML support is feasible. It’s the only one that has both a native code compiler and a REPL. MLton and MLKit have their strong sides, but no REPL.

    1. 1

      I don’t think that anything inherent to the design of either smlpkg or futhark-pkg (which smlpkg is built on) locks you to GitHub og GitLab. They are supported right now, for pragmatic reasons, but there’s nothing stopping you (or someone else) from adding another repository, as far as I’ve understood.

      Additionally, I’ll point out that this package manager is pretty compiler-agnostic. The current implementation might only compile using MLKit or MLton, but the executable can be used to manage packages for projects written for any distribution of ML.

      Finally, I’ll point out that MosML also has both a native code compiler and a REPL.

      1. 1

        Poly/ML doesn’t use mlb format. The way I’ve considered handling both is to have a pre-processing step that maps a standard configuration (possibly mlb) to both mlbs and Poly/ML style includes.

        1. 1

          Yeah, I was thinking of something like that. Then again, I wonder if Poly/ML’s maintainer is against .mlb, or a patch for supporting both styles can be accepted.

          And then there’s a third option: a retargetable equivalent of OCaml’s findlib, separate from the package manager.

          1. 2

            A quick search doesn’t turn anything up. These programs have existed for so long I assume David has a reason not to have added mlb support, but I can’t remember seeing anything.

            To my surprise (I must have forgotten), SML/NJ has their own style too: CM files.

            So for now, a pre-processing step is probably the least friction approach to supporting the major implementations.