| 30 Jul 2021 |
 @d4hines:matrix.org | *
Then, typically, somebody integrates that tool into nixpkgs to create a repo of all (or most) of the available packages
Wait, how does that work? Let's say it's npm2nix. There are dozens of versions of package X on npm that live side-by-side, but nixpkgs has exactly 1 version per version of nixpkgs, right?
| 15:53:15 |
| @d4hines:matrix.org | *
Then, typically, somebody integrates that tool into nixpkgs to create a repo of all (or most) of the available packages
Wait, how does that work? Let's say it's npm2nix. There are dozens of versions of package X on npm that live side-by-side, but nixpkgs has exactly 1 version per version of nixpkgs, right?
| 15:53:24 |
 @timdeh:matrix.org | Yes, although some times there are multiple versions of the repo for different versions of node. I think atm there is nodePackages and nodePackages_latest. If I understand ericson's RFC correctly though, this would become a bit more dynamic and one could pull whichever version they like. | 15:56:00 |
| @timdeh:matrix.org | Since your colleague is already started with an overlay approach, you might at least be able to use nvfetcher as a stop gap until a more permanent solution arrives via either a proper 2nix wrapper, or the RFC mentioned materializes. It would at least make package source updates a little less painful. | 15:59:34 |
| @d4hines:matrix.org | So let's talk about how nvfetcher would look:
- I would create a flakes repo a lot like this one https://github.com/berberman/flakes, and use nvfetcher to manager versions. We'll call my_flake
- I would create a Tezos flake that takes as input some version of nixpkgs and my_flake, and uses my_flake as an overlay over nixpkgs
- From there I can build as normal.
| 16:05:24 |
| @d4hines:matrix.org | As for our other projects, do you know off the top of your head if it's possible to build esy in Nix, and just use esy's functionality from there? I know there are some issues with this, namely that Esy also wants to control all the dependencies | 16:06:33 |
| @timdeh:matrix.org | Yes, you don't necessarily have to break out the overlay into a separate flake though. That's just a stylistic decision. At work we typically just stick to a single overlay.nix file at the root of the project for example, and then pull that in as the flakes overlay output.
As for using esy as is with Nix, you could attempt to use a fixed-output derivation to give esy network access and generate whatever it generates. Don't know enough about it yet to know if that would work or be simple enough though.
| 16:13:42 |
| @d4hines:matrix.org | In general, are there strategies for an "escape hatch" with NIx? That's something that worries me before I fully switch over to NixOS. | 16:17:10 |
| @d4hines:matrix.org |
That's just a stylistic decision. At work we typically just stick to a single overlay.nix
Are there any open source examples you can share with me? I'd love to see an orchestration of nvfetcher, overlays, and flakes together.
| 16:18:53 |
| @timdeh:matrix.org | The fixed-output derivation could be considered a type of escape hatch, where the derivation is allowed to make network calls under the condition that the final result matches a user supplied hash. There is also the buildFHS helper to simulate a traditional FHS environment when needed. It's also pretty simple to declaratively spin up oci or docker containers when you need them as well. | 16:21:38 |
| @timdeh:matrix.org | as for a good example of nvfetcher, I just recently integrated my devos install with it (it was merged fairly recently). I haven't even pushed it yet, because I was working out some errors yesterday, but it's fully working now so I can probably push it here in a bit and send you a link. I've also been thinking about integrating nvfetcher at work for some of our vendored packages, but I haven't started that yet. | 16:22:45 |
 David Arnold (blaggacao) | In reply to @d4hines:matrix.org
Then, typically, somebody integrates that tool into nixpkgs to create a repo of all (or most) of the available packages
Wait, how does that work? Let's say it's npm2nix. There are dozens of versions of package X on npm that live side-by-side, but nixpkgs has exactly 1 version per version of nixpkgs, right?
I can recommend https://www.tweag.io/blog/2021-03-04-gomod2nix/ | 16:23:03 |
| David Arnold (blaggacao) | Very interesting discussion! So an intermediate resume would be (in order of "nixonicness"): *2nix -> nvfetcher -> fixed output with target ecosystem tooling | 16:28:50 |
| David Arnold (blaggacao) | My takeaway here is that nvfetcher can actually sit somewhere in the middleground, here | 16:29:46 |
| David Arnold (blaggacao) | (if that makes sense) | 16:29:57 |
| @d4hines:matrix.org | At this stage very little Nix usage makes sense to me 😆 | 16:30:31 |
| @d4hines:matrix.org | I've read through some of the Nix pills and I've gotten DevOS working, and that's about it. It's quite a learning curve | 16:30:56 |
| @d4hines:matrix.org | So any concrete examples would be super appreciated | 16:31:20 |
| David Arnold (blaggacao) | RFC92 fit's in in that it "defers" evaluation of an "input from derivation" that wraps ecosystem tooling (like esy, etc.) so long as as a text hash of those defered insturctions can be always expected to produce the same outpu. | 16:32:31 |
| David Arnold (blaggacao) | * RFC92 fit's in in that it "defers" evaluation of an "input from derivation" that wraps ecosystem tooling (like esy, etc.) so long as as a text hash of those defered ecosystem instructions can be always expected to produce the same output | 16:32:52 |
| David Arnold (blaggacao) | (or at least that is my understanding of that RFC) | 16:33:57 |
| David Arnold (blaggacao) | In reply to @d4hines:matrix.org
I've read through some of the Nix pills and I've gotten DevOS working, and that's about it. It's quite a learning curve Honestly, I don't find the nix-pills super useful. But I guess we don't yet live up to rust standards in terms of docs 😃🦧 | 16:34:57 |
| @d4hines:matrix.org | In reply to @blaggacao:matrix.org
Honestly, I don't find the nix-pills super useful. But I guess we don't yet live up to rust standards in terms of docs 😃🦧 Do you have any recommendations on how to get to "journeyman status" in Nix? | 16:36:11 |
 yusdacra | The only docs I've read was the manuals, was enough for me personally. I got bored of nix pills 😛 | 16:36:20 |
| yusdacra | Oh and reading nixpkgs derivations. | 16:36:35 |
| David Arnold (blaggacao) | In reply to @d4hines:matrix.org
Do you have any recommendations on how to get to "journeyman status" in Nix? For me, it was contributing to devos 😃😂 | 16:37:31 |
| David Arnold (blaggacao) | The biggest hurdle was 1) no good IDE support 2) really awkward tracing and debugging workflows. | 16:38:21 |
| @d4hines:matrix.org | "infinite recursion encountered" lol | 16:38:45 |
| @d4hines:matrix.org | That's what I get whenever I try to modify the overlay | 16:39:00 |
| David Arnold (blaggacao) | For tracing I find this flag useful: --override-input nixos path:/absolute/path/to/local/workdir/of/nixpkgs/with/a/few/traces | 16:39:47 |
