New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

elm2nix #20601

Closed
domenkozar opened this Issue Nov 21, 2016 · 10 comments

Comments

Projects
None yet
7 participants
@domenkozar
Copy link
Member

domenkozar commented Nov 21, 2016

Elm is written in Haskell and has a very sane package manager. It shouldn't be too hard to be able to deploy all Elm packages with Nix.

I don't have enough free time to program this atm, but I'd like to drop my research here how I'd do it.

Generating all packages

Elm serves a single JSON (per Elm release) that returns all packages registered upstream:

http://package.elm-lang.org/all-packages (Elm 0.18)

We'd have to create a storage (git repository) with the following metadata per package:

  • generate sha256 of the tarball downloaded from github
  • elm-package.json (for later processing)

As usual, we'd then build all packages and provide binaries (probably not on hydra.nixos.org).

elm2nix

It would use Elm haskell API to determine the latest versions based on local elm-package.json and generate default.nix to be used to build your project.

Functions for generating versions and names:

https://github.com/elm-lang/elm-compiler/blob/master/src/Elm/Package.hs

Logic that determines if file should be downloaded (and thus where to unpack Nixified elm packages): https://github.com/elm-lang/elm-package/blob/master/src/Install/Fetch.hs#L137

Nix integration would just unpack packages to folders like ./elm-stuff/packages/debois/elm-dom/1.2.2/ and then run elm install . in order to avoid networking at build time.

Questions

  1. what if it uses the newest package that is not already indexed by Nix?

This one is tricky, as it's impossible to be able to be up to date without some delay unless a user was able to generate a new set or be able to override (manual work).

We'd have to research if elm install does lookup local folders first and just use those instead of the very latest upon installation.

Relevant work

My estimate is about a few days of work to get a prototype working :)

cc @garbas

domenkozar referenced this issue in aforemny/elm2nix Nov 21, 2016

@zimbatm

This comment has been minimized.

Copy link
Member

zimbatm commented Nov 21, 2016

Do you think we can get upstream to publish the sha256 with each package? That would simplify the pipeline a lot.

@domenkozar

This comment has been minimized.

Copy link
Member

domenkozar commented Nov 21, 2016

We'd also need for them to store elm-package.json to generate the dependencies.

I think it's worth trying upstream first.

@Ericson2314

This comment has been minimized.

Copy link
Member

Ericson2314 commented Nov 21, 2016

I'd be interested to try out the architecture I proposed in haskell/cabal#3882. (It sounds like your plan is somewhere in between that and the cabal2nix approach.)

@garbas

This comment has been minimized.

Copy link
Contributor

garbas commented Nov 24, 2016

Hi,

I would be -1 on having this information in nixpkgs and updating them in place. I would rather see a new repository eg. nixpkgs-elm which would accept nixpkgs as an input. I started this for python I think could easily setup the same thing for Elm.

I find it more and more that when working on different project you also need to pick different revision of nixpkgs. Having a collection of language specific packages and switching between different nixpkgs version is a crucial for me this days.

ofcourse nixpks-elm repository can also have an entry in nixpkgs via fetchGitHub for specific revision.

for those interested in Elm. there actually already is elm2nix command but you need to check the files and comments in pkgs/development/compilers/elm. At Mozilla we then have an update script which runs this on nightly basis: https://github.com/mozilla-releng/services/blob/master/nix/lib/default.nix#L384. for now this is working ok but it would be even better if we would have this already packaged in nix.

my 2c

@domenkozar

This comment has been minimized.

Copy link
Member

domenkozar commented Nov 24, 2016

I never proposed for packages to be in nixpkgs, since they wouldn't be built anyway :)

But this is irrelevant and minor compared to making the infrastructure work.

@Ericson2314 that means involving upstream and looks like the timing is right: elm/package.elm-lang.org#208

@FRidh

This comment has been minimized.

Copy link
Member

FRidh commented Nov 24, 2016

Unless we have other packages depending on the Elm packages it's fine keeping it entirely separate from Nixpkgs. As soon as Nixpkgs packages do depend on the Elm packages we might start using fetchTarball with hash.

@domenkozar

This comment has been minimized.

Copy link
Member

domenkozar commented Mar 24, 2017

I'll wait for Elm 0.19 before automating this, since it's going to help a lot: https://groups.google.com/forum/#!topic/elm-dev/qdu3NqOqGrY

@domenkozar

This comment has been minimized.

Copy link
Member

domenkozar commented Dec 14, 2017

I took a bit different path and made https://github.com/domenkozar/elm2nix today. Wanted it to be simple so it can be done within a day. Let me know what you think!

@tomberek

This comment has been minimized.

Copy link
Contributor

tomberek commented Oct 10, 2018

close as old?

@zimbatm zimbatm closed this Oct 10, 2018

@domenkozar

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment