<angerman>
elvishjerricco: right, so it would be a shorthand for that.
<elvishjerricco>
angerman: Just trying to help make things more concise than `fetchFromGitHub` without new language features :P
<angerman>
I guess I could write a custom parser that parsed "github:owner/repo@rev;hash". I'm only a bit concerned that that would be hilariously slow in nix
<angerman>
elvishjerricco: anyway, as you can see I managed to use your plan2nix logic to actually build nix-tools :D
<elvishjerricco>
angerman: Cool :) Soon I'm gonna try to make a module based Nix infra for Haskell. Hoping to make nix-tools the backbone of it.
<angerman>
module based? cabal components?
<elvishjerricco>
So when I get to that, I'll be fixing up my PR and making it more usable
<elvishjerricco>
angerman: NixOS-style modules; modules in the Nix infra, not Haskell modules
<angerman>
guess I have no idea about modules; but I need a componentized builder
<elvishjerricco>
angerman: Yea, that's one of the things I want for my thing. That PR I've got already does that
<elvishjerricco>
Componentized builds are sooo much better...
<angerman>
elvishjerricco: how much further are you along the way than what the open PR has?
<elvishjerricco>
angerman: Zero.
<elvishjerricco>
angerman: Hopefully I can get to it soon...
<angerman>
elvishjerricco: but you still ran tests as part of the component builder logic, or did I miss something?
<angerman>
elvishjerricco: I'd ideally want something like <pkg> being the library, and <pkg-test-x> being the test-suite x; and similarly <pkg-exe-x> being the executable x.
<elvishjerricco>
angerman: It's already usable as-is. You can generate a hackage Nix DB and use a stack config or a cabal plan and the new generic-builder I've got in there to get per component builds. You reference the build like `foo.components.exes.foo`
<angerman>
e.g. one cabal file would become multiple derivations. That way I can depend only on the libraries, and I'd also like to split out the tests into separate derivations so that I can run the in parallel and opportunistically try compiling dependent packages as soon as the library is built.
<elvishjerricco>
Yea, exactly what my thing already does :)
<angerman>
elvishjerricco: ok. I'll need to have another look.
<elvishjerricco>
angerman: It's not *at all* cross friendly yet, but it's small enough that it shouldn't be hard to add
<angerman>
I needed to nuke the revision stuff for now though. I *am* in favor or dumping hackage.nix.
<elvishjerricco>
angerman: I worry about a full Hackage DB in Nix because it's pretty monstrous
<angerman>
clever: ^^
<elvishjerricco>
Like hundreds of megs (maybe over a gig... can't remember)
<elvishjerricco>
It's like 44M compressed though
<elvishjerricco>
Which brings us to a Nix feature I'd like :P
<angerman>
elvishjerricco: well if you look what I do with nix-pkgs, I just fetch a snapshot.
<elvishjerricco>
Importing files from tarballs as if it were a directory, so that relative path literals in the imported expression works
<angerman>
elvishjerricco: one thing I was wondering about the other day was, what if we wrote a compression algorithm in nix? and would decode stuff on the fly? :p
<elvishjerricco>
Lol
<elvishjerricco>
A bit extreme, but that might do it :P
<angerman>
elvishjerricco: 14M Oct 10 21:22 20ad44ecdd5475c8adbe0e129638f729a26ca120.tar.gz
<angerman>
that's the hackage.nix snapshot.
<elvishjerricco>
angerman: How did you generate that?
<angerman>
elvishjerricco: to be fair, it's a processed hackage. E.g. it already throws away lots of info from the cabal files that the cabal-to-nix tool doesn't use.
<angerman>
so you should naturally end up with a smaller file
<angerman>
elvishjerricco: I'm planing on having the update.sh script in hackage.nix and stackage.nix run every 4hrs; and then commit that with UTC timestamps as git tags.
<angerman>
or maybe every 6hs.
<elvishjerricco>
angerman: How is hackage.nix generated again? That's from all-cabal-hashes, isn't it?
<elvishjerricco>
angerman: And how big is the archive uncompressed?
<angerman>
407mb
<angerman>
might have slight variation due to FS though.
<angerman>
elvishjerricco: however that brings us back to the question if nix could just look into turbals.
<elvishjerricco>
angerman: Exactly. I don't mind a < 100M file for each project. But approaching half a gig is pretty bad.
<angerman>
I'd be more concerned about the number of files
<elvishjerricco>
angerman: Why's that?
<angerman>
you have massive amounts of small files; that's annoying and might put a strain on your f.
<angerman>
filesystem.
<elvishjerricco>
Good point
<angerman>
elvishjerricco: but wait it wouldn't be 400mb per project.
<angerman>
elvishjerricco: nix will cache that for you. If you use a consisted hackage.nix snapshot across your projects; you will only have 400mb once.
<elvishjerricco>
Yea but each project will probably want to pin it themselves, all told.
<angerman>
well...
<angerman>
elvishjerricco: do you have an example on how you call your custom builder, you could attach to the issue?
<angerman>
elvishjerricco: the component build might end up being fixed faster than you might think. Any help/guidance could be helpful.
<elvishjerricco>
angerman: Let me dig it up... Haven't used it in a while so I'll have to figure it out again :P
<angerman>
sure!
<clever>
morning
<domenkozar>
nixos weekly with only NixOS release in it?
<elvishjerricco>
angerman: Huh. Data.Yaml can't parse lts-12.0.yaml for some reason....
<domenkozar>
yay/nay? :)
<domenkozar>
any last minute articles for nixos weekly? :)
<elvishjerricco>
angerman: Derp. Need lts-to-nix
<elvishjerricco>
domenkozar: Oh I might have something
<domenkozar>
I don't understand why that article was written as hydra tutorial does the same in more automated way
<domenkozar>
but I'll post it anyway :)
<elvishjerricco>
domenkozar: I haven't actually read it :P
<domenkozar>
I skimmed it and seems like 101 tutorial for hydra
<domenkozar>
so fastly, 18.09 and hydra tutorial
<domenkozar>
sure why not.
<angerman>
elvishjerricco: ??
<elvishjerricco>
?
<elvishjerricco>
Oh
<elvishjerricco>
I was trying to use stack-to-nix on an lts.yaml file, not a stack.yaml
<elvishjerricco>
I'm dumb :P
<elvishjerricco>
Needed lts-to-nix
ekleog has quit [Remote host closed the connection]
aminechikhaoui has joined #nixos-dev
ekleog has joined #nixos-dev
mic921 has joined #nixos-dev
jtojnar has joined #nixos-dev
Dezgeg has joined #nixos-dev
pie_ has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 252 seconds]
globin has joined #nixos-dev
orivej has joined #nixos-dev
<globin>
domenkozar, gchristensen, niksnut: fpletz and I would like to propose sphalerite (lheckemann on github) as a nixpkgs committer/member, he has had 100 PRs merged and is also very active on IRC/discourse. (full disclosure, he's started working at mayflower and at least until the end of this year he'll be working full time on open source nix related things). (merged PRs: