Re: Elm and Guix

[Philip McGrath]

Hi,

On 9/13/22 20:27, jgart wrote:
> From: jgart <jgart@dismail.de>
> To: Guix Help <help-guix@gnu.org>
> Cc: Philip McGrath <philip@philipmcgrath.com>
> Bcc:
> Subject: Using elm with Guix
> Reply-To:
> In-Reply-To:
>
> Hi,
>
> I'v been trying to use elm with Guix at the repl and by compiling a
> src/Main.elm file and elm doesn't find any of the Guix-installed dependencies:

I think there are a few different things going on here.

> ```
>   guix-shell  elm make src/Main.elm
> Detected problems in 1 module.
> -- MODULE NOT FOUND ----------------------------------------------- src/Main.elm
>
> You are trying to import a `Http` module:
>
> 10| import Http
>             ^^^^
> I checked the "dependencies" and "source-directories" listed in your elm.json,
> but I cannot find it! Maybe it is a typo for one of these names?
>
>      Set
>      Dict
>      Main
>      Task
>
> Hint: Maybe you want the `Http` module defined in the elm/http package? Running
> elm install elm/http should make it available!
> ```
>
> Is there a way that I'm supposed to be using elm with Guix in order to
> discover the dependencies.

This part of the problem doesn't seem to involve Guix.

As you may know, Elm "module"s (files like "Main.elm" or "Http.elm") are 
organized in "project"s, where a project is either a "package" or an 
"application". Every Elm "project" must include a file called "elm.json" 
declaring the project's structure and dependencies. Unlike many 
languages, Elm doesn't have a concept of modules outside of a project, 
nor of globally installed packages: when compiling `import Http` in your 
"src/Main.elm", Elm will look for an `Http` module that is either part 
of the same project---i.e. a file "src/Http.elm", unless anything is 
configured unusually---or in one of the Elm packages listed in the 
"elm.json" file.

In other words, Elm never "discovers" dependencies. That's true even for 
the modules from "elm/core" package!

What this error message is saying is that your "elm.json" file doesn't 
declare a dependency on the "elm/http" package, so there's no `Http` 
module available. You could edit the "elm.json" file by hand, but you'd 
have to get indirect dependencies and versions right. The command 
suggested in the error message:

    elm install elm/http

will edit your "elm.json" file for you to declare the additional 
dependency. For a useful example, look at:

    guix build --source elm-todomvc


> The usage of this for elm developers using Guix looks undocumented.
>
> What I tried:
>
> ```
> guix shell elm elm-json elm-html emacs-http
>
> mkdir elm_play
> cd elm_play
> elm init
> elm make src/Main.elm
> ```

Here, though, we get to some issues that do involve Guix: in particular, 
using `guix shell` to install `elm-json` and `elm-html` isn't 
(currently?) helpful for interactive development in the way you would 
hope. First I'll try to explain two ways of using Guix for Elm 
development that do work; then I'll explain the unresolved issues here.

One option is to use Guix to install `elm`, but then let Elm manage 
other Elm packages you need for interactive development. This is 
analogous to using Guix to install Python or Node, then installing 
packages with `pip` or `npm`. (Maybe it's a little better than that, in 
that Elm has very stringent requirements enforced by the compiler to 
avoid some of the hairy problems with e.g. npm packages.)

Another option is to define a Guix package for your Elm project using 
`local-file` in the origin, and then, instead of `elm make`, build your 
project with e.g.:

    guix build -f elm_play.scm

In that case, `guix import elm` may be useful for any of your packages 
that aren't already in Guix, and the package definition for elm-todomvc 
would be a good example to imitate. In particular, either you need to 
make sure that your "elm.json" file matches the versions of your 
dependencies packaged in Guix or you should make use of the the 
`patch-application-dependencies` procedure as suggested in the 
documentation for `elm-build-system`.

The problem with:

    guix shell elm elm-json elm-html elm-http

(I assume you didn't mean `emacs-http`) is that it won't put the built 
Elm packages in a place where Elm can find them.

Elm looks for installed packages in a single directory, either "~/.elm" 
(IIRC) or the value of the ELM_HOME environment variable, if it's set. 
We of course have functions to assemble such a directory in 
"guix/build/elm-build-system.scm", and we could expose them either via a 
package-generating function (analogous to texlive-updmap.cfg`) or even a 
profile hook.

The deeper issue is that Elm sometimes tries to write to existing 
"artifacts.dat" files in ELM_HOME: this is also the cause of the caveat 
about multiple versions of the same Elm package not tending to coexist 
well in a single Guix build environment, even though that's supported at 
the Elm level. I haven't dug deep enough into the internals of the Elm 
compiler to figure out exactly what's going on.

It's possible that the very limited support for working offline I 
patched into Elm for Guix might be enough to work around this, if you 
want to set up an environment with an ELM_HOME managed exclusively by 
Guix. Alternatively, it could be interesting to explore patching Elm 
further to not try to overwrite "artifacts.dat" files and look for 
packages in an additive way, perhaps using XDG_DATA_DIRS. If you're 
interested in exploring any of that, I wrote comments in 
"guix/build/elm-build-system.scm" and 
"gnu/packages/patches/elm-offline-package-registry.patch" with ideas, 
and IIRC there was some informative discussion upstream at 
<https://discourse.elm-lang.org/t/private-package-tool-spec/6779/25> and 
maybe related to `elm-test-rs` 
<https://github.com/mpizenberg/elm-test-rs>, and probably other places. 
If we came up with a nice approach, I hope upstream might be open to 
patches, especially since the Elm community is enthusiastic about 
immutability.

Anyway, I hope this helps, and let me know how it goes! I'm glad the 
support for Elm in Guix so far is interesting, and I think having more 
people try it will be the best way to figure out how we might be able to 
improve on it.

-Philip