Hi folks.
Over time I’ve seen several issues related to getting some of the elm toolings run on NixOS or using Nix package manager.
I just want to let you know that I’ve made this repository with scripts to install some of the tools via nix. More detailed description can be found on GitHub.
Issues and PRs are welcome.
this is great, thanks for setting it up! I’ve felt the pain of not having elm-test a bunch lately… node2nix is not a super fun tool to use!
I wonder if you would consider making this into a NUR package? Then anyone with the NUR channel configured can do like nix-env -iA nur.repos.turboMaCk.elm-test!
oh yeah, and if you’d like help setting up a Cachix cache for this let me know!
I think we can try to go remote install friendly derivation > NUR > nixpkgs if possible. Of course over course of some time with respect to those upstreams.
I was just thinking about setting up Cachix. Seem that builds are reasonably fast but I just merged optional builds of elmi-to-json from the source. So steps I have in mind now are:
Feel free to open any PR / issue or make any suggestion what to do with it. What I would love to see is with this becoming base of community controlled solution in the future as with things like this it’s always nice to share fixes and improvements. I really believe elm dev experience on NixOS can be much much better out of the box without that much work. All it takes is a little bit and all the folks adopting nix after won’t need to spend hours solving issues.
- Remove all the hacks in upstream packages to make them nix compatible out of the box.
- Implement custom nix specific builds for elm tooling with nix specific patches.
Given that nix users makes only for a tiny fraction elm community I believe it would be naive to try to enforce compatibility directly in upstream packages and therefore this project uses 2nd approach to provide elm lang tooling to nix community.
FYI, as the maintainer of elm-format, I am interested in having the distributions directly support nix (approach #1). Also, the reason I made binwrap a reusable library instead of just packaging elm-format manually was so that any improvements could be easily shared with anyone wanting to package an app.
Anyway, to summarize, I can’t speak for other maintainers, but I’m interested in improving elm-format and binwrap toward approach #1. (And my hope is that any improvements to binwrap will make it easy for other maintainers to benefit form those improvements.)
That’s good to hear @avh4. In my opinion we need to be careful around changes in binwrap. It might be problematic on NixOS right now but it provides support for Mac, Windows and plenty of Linux distros. In my opinion it’s better to be slightly more defensive - we should avoid breaking what is working fine.
Furthermore I don’t think the issue is with binwrap itself but with the way it’s used in npm scripts. I was thinking I about patching it in a way so that binwrap would work as usual but than I though nixpkgs way is usually to build from source and cache the binary so this approach (not using binwrap) is more nixpkgs way in the end I think.
Not sure if you know but elm-format is already in nixpkgs so anyone on NixOS or with nix can just install it via nix-env -i elmPackages.elm-format.
I have a few updates to share.
Once the other PR is resolved - either accepted or closed I’m going to shift focus on other parts.
@avh4 I find some time I can also look more closely to the binwrap issue but I can’t really promise anything. I still think with nix we would be better off bypassing binwrap and compiling everything to dynamically linked libraries.
@brian if you want to help I can make you collaborator in the repo
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.