elm: dealing with multiple versions of packages

elm: dealing with multiple versions of packages

[Robert Vollmert]

Hi,

I’m trying to figure out how to package elm apps nicely. There are:

- elm apps, which typically result in some compiled elm code as *.js
files, and which depend on a number of elm “packages” by precise
version.
- elm packages, libraries of elm source; as usual, these come in
various versions. I’d package these as pure source bundles, so their
individual dependency information won’t be reflected in Guix, that
will be left to apps.

My question now is how to deal with multiple versions of the same
elm package, e.g “elm/browser”. My own app I’m trying to package
depends on “elm/browser” 1.0.1, while e.g. the elm reactor which
is distributed with elm depends on 1.0.0. (To start with, I’d
rather not get into the business of rewriting specified dependencies
to point to the latest compatible version, so both apps should
depend on different guix packages.)

I’ve thought of some ways of encoding this, but am unsure of what
would fit well (and how similar situations are solved elsewhere
in Guix).

1. multiple independent top level definitions, perhaps inherited, e.g.

(define-public elm-browser-1.0.0
  (package …))

(define-public elm-browser-1.0.1
  (package (inherit elm-browser-1.0.0) …))

2. extract the version-specific part to data, and define a function
mapping version to package, along the lines of

(define-public (elm-browser version)
  (define versions
    ‘((“1.0.0” . "1zlmx672glg7fdgkvh5jm47y85pv7pdfr5mkhg6x7ar6k000vyka”)
      (“1.0.1” . “1l0qdbczw91kzz8sx5d5zwz9x662bspy7p21dsr3f2rigxiix2as”)))
  (package
    (name “elm-browser”)
    (version version)
    (source (… (assoc-ref versions version)))))

3. as a variant of 2., define a top-level association list mapping version
to package definition

4. don’t define global packages at all, but inline them into the app
dependencies

Thanks,
Robert