DevOS | 33 Members | |
| Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga | 10 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Jul 2021 | ||
| So the way most of the 2nix wrappers work is essentially what you describe yes. A standalone tool that can be used to convert some sort of lock or package format to nix fetch expressions. Then, typically, somebody integrates that tool into nixpkgs to create a repo of all (or most) of the available packages | 15:51:31 | |
| There is also an open RFC which could help to improve this situation a bit, and make this type of thing more Nix native | 15:52:44 | |
Then, typically, somebody integrates that tool into nixpkgs to create a repo of all (or most) of the available packages | 15:53:02 | |
| * 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 | |
*
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 | |
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 | |
| 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 | |
| So let's talk about how nvfetcher would look:
| 16:05:24 | |
| 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 | |
| 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 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 | |
| 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 | |
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 | |
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 | |
| 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 | |
In reply to @d4hines:matrix.orgI can recommend https://www.tweag.io/blog/2021-03-04-gomod2nix/ | 16:23:03 | |
| Very interesting discussion! So an intermediate resume would be (in order of "nixonicness"): *2nix -> nvfetcher -> fixed output with target ecosystem tooling | 16:28:50 | |
My takeaway here is that nvfetcher can actually sit somewhere in the middleground, here | 16:29:46 | |
| (if that makes sense) | 16:29:57 | |
| At this stage very little Nix usage makes sense to me 😆 | 16:30:31 | |
| 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 | |
| So any concrete examples would be super appreciated | 16:31:20 | |
| 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 | |
| * 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 | |
| (or at least that is my understanding of that RFC) | 16:33:57 | |
In reply to @d4hines:matrix.orgHonestly, 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 | |
In reply to @blaggacao:matrix.orgDo you have any recommendations on how to get to "journeyman status" in Nix? | 16:36:11 | |
| The only docs I've read was the manuals, was enough for me personally. I got bored of nix pills 😛 | 16:36:20 | |
| Oh and reading nixpkgs derivations. | 16:36:35 | |
In reply to @d4hines:matrix.orgFor me, it was contributing to devos 😃😂 | 16:37:31 | |
| The biggest hurdle was 1) no good IDE support 2) really awkward tracing and debugging workflows. | 16:38:21 | |