elm-land: Rewrite and migrate from elmPackages to pkgs/by-name

[Kranzes]

Supersedes: #382339

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Kranzes]

Should I add an alias from pkgs.elmPackages.elm-land to pkgs.elm-land?

[zupo]

Doesn't seem to work on nix-darwin.

../result/bin/elm-land server does say Elm Land (v0.20.1) is ready at http://localhost:1234, but nothing happens in my browser when I do to this address.

[turboMaCk]

@zupo what does lsof -i :1234 returns in that state?

[zupo]

lsof -i :1234

COMMAND     PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
node       7231 zupo   13u  IPv4 0xf221e680ffb1b9d6      0t0  TCP *:search-agent (LISTEN)
ssh       87800 zupo    5u  IPv6 0x8dc076cf21014dda      0t0  TCP localhost:search-agent (LISTEN)
ssh       87800 zupo    6u  IPv4 0x16cc71eabb3ccfdf      0t0  TCP localhost:search-agent (LISTEN)
Google    99313 zupo   38u  IPv6 0x731ae9acde4f50c3      0t0  TCP localhost:49474->localhost:search-agent (CLOSE_WAIT)

elm-land build seems to work fine.

[turboMaCk]

you can see that node is attached to the port from pid 7231 that will probably be the elm-land process. But chrome is stuck in CLOSE_WAIT which I believe suggests the server closed the connection but chrome did not. What is a bit sus is that server is on ipv4 while chrome is connecting via ipv6. But I'm not an expert on networking especially in macos - But my guess is that problem is not with the package.

if you have non nixified version running locally you can compare what that does. It might be attaching to the port using ipv6 perhaps? I think you maybe can even fix this in your hostfile - maybe you're not binding localhost to ipv4 address. I would also definitely try accessing http://127.0.0.1:1234 directly.

[zupo]

@turboMaCk: thank you for taking the time to help me. It's definitely my machine/browser. curl works just fine. @Kranzes: sorry for the noise!

[zupo]

Verified the latest commit works on macOS!

[turboMaCk]

@Kranzes is there anything missing? I see this is still ina Draft.

[Kranzes]

@Kranzes is there anything missing? I see this is still ina Draft.

Should be good now. @zupo wanted to write a test but I just tried to do that and I think it will be quite difficult because of the sandbox, it tries to fetch the packages list from the registry, which requires a network connection.

[turboMaCk]

Honestly I'm OK not doing test for this case. But I'm not sure how exactly this regressed either so I don't even have an idea about what could make sense to test.

Plus this package is now completely decoupled from most things (apart from elm compiler).

[turboMaCk]

LGTM

[PedroHLC]

Diff LGTM.

[zupo]

@Kranzes is there anything missing? I see this is still ina Draft.

Should be good now. @zupo wanted to write a test but I just tried to do that and I think it will be quite difficult because of the sandbox, it tries to fetch the packages list from the registry, which requires a network connection.

I was dreading that 😱. In any case, having the test in a later PR is perfectly fine. Thanks again for fixing this!

[turboMaCk]

I think the danger of regression was in this case mitigated by decoupling the package from unified node2nix packages. Any update of this will from now on be intentional.