 | DevOS | 37 Members |
| Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga | 10 Servers |
| DevOS | 37 Members |
| Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga | 10 Servers |
| Sender | Message | Time |
|---|---|---|
| 29 Jul 2021 | ||
 @teutat3s:pub.solar | I could also update the lockfile more fine-grained if you'd prefer that | 16:21:38 |
 David Arnold (blaggacao) | No, I guess some of them are overdue anyhow. In the end I guess the responsibility for the lock file management (outside of what bors test might report) would have to lie with the users. | 16:27:16 |
| David Arnold (blaggacao) | Not sure if this faile reproducibly | 16:29:45 |
| David Arnold (blaggacao) | * Not sure if this faile reproducibly: https://github.com/divnix/devos/runs/3193959663 ? | 16:29:52 |
 @timdeh:matrix.org | https://github.com/dramforever/nix-dram/issues/10 | 17:27:44 |
 d4hines joined the room. | 20:30:32 | |
| d4hines | 👋 Hey guys. Super impressed by the DevOS project - it's made the jump to NixOS a lot friendlier. One thing I'm still confused on as a Nix noob is the lack of convention. I want everything fully reproducible, and I think that means using either flakes or something like Niv. I lean towards flakes by default because it seems like the direction Nix is going long term. But even when using flakes, it's not clear how to structure a project. Should every dependency be a github repo input to the flake? Or just NixPkgs plus Nix expression libraries? Or some combination (how do I decide?). In my dream world, everything is in a devshell TOML which is locked by a flake lockfile. How do I get there? | 20:39:56 |
| d4hines | Also, meta-question - what chat client do you guys use on NixOS? I'm hate juggling Slack, Discord, and now Matrix, but I'm not sure if there's a better way. | 20:41:17 |
| @teutat3s:pub.solar | In reply to @blaggacao:matrix.org works in the locally checked out develop branch with that commit (exit code 0) | 22:40:57 |
| @teutat3s:pub.solar | In reply to @d4hines:matrix.orgThere's the possibility to use bridges to bundle your chats in Matrix (using the Element chat client), but not sure if that's a better way | 22:43:18 |
| 30 Jul 2021 | ||
| @timdeh:matrix.org | d4hines: welcome to the room. Glad to know our work has been useful. As for the chat juggling, I'm in the exact same boat unfortunately 😕 Except that you can also add in signal-desktop to the mix 😆 In terms of how to structure the project, I think it is still to early to say what is idiomatic for flakes. For example, we used to use flake inputs as a source fetcher for packages, but we did this in a subflake of devos and the whole thing was very brittle and unintuitive, so we switched source fetching to nvfetcher, and after using it, I have to say it was a good decision. So I guess our approach atm would be the second one you mentioned, i.e. only using flake inputs for nix expressions, and using nvfetcher or similar tool (or just hand coding it) to update package sources. | 15:31:11 |
| @timdeh:matrix.org | * d4hines: welcome to the room. Glad to know our work has been useful. As for the chat juggling, I'm in the exact same boat unfortunately 😕 Except that you can also add in signal-desktop to the mix 😆 In terms of how to structure the project, I think it is still too early to say what is idiomatic for flakes. For example, we used to use flake inputs as a source fetcher for packages, but we did this in a subflake of devos and the whole thing was very brittle and unintuitive, so we switched source fetching to nvfetcher, and after using it, I have to say it was a good decision. So I guess our approach atm would be the second one you mentioned, i.e. only using flake inputs for nix expressions, and using nvfetcher or similar tool (or just hand coding it) to update package sources. | 15:31:25 |
| d4hines | Wow, haven't heard of nvfetcher - so confused 😆 Maybe you guys could give me your recommended approach on a concrete problem. I work on the Tezos blockchain, which is a large OCaml project. So naturally we have lots of OCaml packages, but also some rust and c dependencies. There's probably about 100-150 dependencies total. If this were Javascript, I would just list them all, and npm would go fetch them, stick them in node_modules, and tadah! webpack or whatever knows where everything is (I'm new to native development if you can't tell). My goal is to get back to something like that if possible. Most of the packages are in nixpkgs already, but some are missing, and some of the versions aren't right, so one of my coworkers has this massive overlay he uses to build it, but it seems like a big mess. How would you guys tackle something like this? One thought I had was to fork nixpkgs and pass it as flake input. Maybe even par it down to just the packages we need. But this also seems like a lot of work. Any direction is greatly appreciated! | 15:40:35 |
| @timdeh:matrix.org | Have you heard of the esy package manager for ocaml? Perhaps this could help you guys out a bit? I was actually wanting to make a wrapper for it at some point or something, so I could eventually write a package for oni2. ATM though, I'm not sure how well this would integrate with Nix. Maybe we could team up on an esy2nix side project 😅 | 15:43:55 |
| d4hines | Actually, I work with the esy maintainers! | 15:44:24 |
| @timdeh:matrix.org | Nice, so are you guys using it in your build chain? | 15:44:50 |
| d4hines | Yes and no. Tezos proper does not use it. However, my company, Marigold, has other projects that integrate with Tezos and we use esy for those. | 15:45:38 |
| d4hines | Let's assume there was an esy2nix. What exactly does this do for us? I guess it means that instead of having to update every OCaml package in nixpkgs, Nix now knows how to fetch and build any OCaml package living in the OPAM repository, right (a lot like package.json/npm, right?) | 15:48:58 |
| d4hines | So we've decoupled OCaml projects in Nix from the nixpkgs repository. | 15:49:40 |
| @timdeh:matrix.org | 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 |
| @timdeh:matrix.org | 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 |
| d4hines | Then, typically, somebody integrates that tool into nixpkgs to create a repo of all (or most) of the available packages | 15:53:02 |
| d4hines | * 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 | *
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 | So let's talk about how nvfetcher would look:
| 16:05:24 |
| d4hines | 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 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 | 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 |