Compiling Elm from Source

Show and Tell
1

Problem in Filling the Elm Package Cache for New Builds

This is related to the Elm Init TLS Issue thread correctly identifying that the problem came about because the GHC Haskell TLS package was updated to “version 2” with breaking changes as to the HTTP protocol requirement as noted there. The culmination of the linked thread is to fix the issue to build Elm using patched NixOS/nixpkgs as per this link, which would work. As noted in the thread, the issue doesn’t appear in currently available binaries from GitHub or from NPM which were build before the TLS package was updated. As noted at the bottom of that thread, the problem is easy to miss if one’s Package Cache is already populated with all of the packages one normally uses, as then there is no need to refresh the Package Cache’s “Registry.dat” file of available packages. The problem does come up when it is required to build the Package Cache from scratch (as when designating a new location with the “ELM_HOME” environmental variable, and/or when needing to add new packages to the Package Cache that one hasn’t used before.

The problem came about partly because, unlike in Elm where it is required that dependent packages be listed including bounds on the version numbers that are supported, in
Evan’s Haskell Elm compiler “elm.cabal” file he didn’t feel a need to put bounds on the supported Haskell package versions. Thus, once TLS version 2 came out with its breaking changes, it happily gets including into the elm build when the cabal package directory cache is updated to include the latest versions. In fact, TLS is a second level dependency caused by the first level cabal-file-listed “http-client-tls” package which is bundled in the “http-client” project download and isn’t even listed in the current “elm.cabal” file.

Since it is unlikely that any PR made to the elm compiler gets merged anytime soon, one can quite easily fix this by making local changes to the “elm.cabal” files as follows:

  1. For the “elm.cabal” file at the project root, change the lines in the “Build-depends:” section as follows:
        http-client,
        http-client-tls,
        http-types,

to as follows:

        tls < 2.0.0,
        http-client < 0.7.19,
        http-client-tls < 0.3.6.4,
        http-types >= 0.8,
  1. For the “elm.cabal” file at the project root/worker, change the lines in the “Build-depends:” section as follows:
        http-client >= 0.6 && < 0.7,
        http-client-tls >= 0.3 && < 0.4,
        http-types >= 0.12 && < 1.0,

to as follows:

        tls < 2.0.0,
        http-client >= 0.6 && < 0.7,
        http-client-tls >= 0.3 && < 0.3.6.4,
        http-types >= 0.12,

These patches avoid the more secure versions of the TLS protocol causing breaking changes and thus solve the problem, although eventually the Elm Package server should likely be updated to use TLS 1.2/1.3 and avoid the problem requiring these version restrictions while also having the advantage of the added security of the more restrictive protocols.

I encountered this problem while experimenting with maintaining backward compatibility to Elm for my “ElmPlus” “un-fork” (meaning I don’t really want to fragment the Elm community any more than it already is - more on another thread)

6 Likes