| 29 Jul 2021 |
 David Arnold (blaggacao) | Is that good or bad? 😁 | 13:42:50 |
 @teutat3s:pub.solar | don't know yet, but it's not the version 0.5.0 I'm expecting to see - so my conclusion is the overlay is not applied in that module yet | 13:43:36 |
| @teutat3s:pub.solar | Trying to go down the rabbit hole into the digga lib and do some tracing there | 13:44:21 |
| David Arnold (blaggacao) | You seem to have a strange latest pinned https://git.b12f.io/pub-solar/os/src/branch/teutat3s-develop/flake.lock#L249 | 13:46:38 |
| David Arnold (blaggacao) | Can you check if that's the correct revision? | 13:46:51 |
| @teutat3s:pub.solar | thanks for taking a look, I'll check | 13:47:04 |
| @teutat3s:pub.solar | https://github.com/NixOS/nixpkgs/commit/0a96dbc8b6bd4874ef0f55ce30ec7bdf1cb09452 indeed seems to be a commit in the release-21.05 branch, not the unstable branch | 13:49:26 |
| @teutat3s:pub.solar | bingo, that seems to be my issue indeed. when setting https://git.b12f.io/pub-solar/os/src/branch/teutat3s-develop/flake.nix#L11 to
latest.url = "nixpkgs/nixos-unstable";
and after doing nix flake update the previous trace shows 0.5.0 as expected 🎉
| 13:53:06 |
| @teutat3s:pub.solar | * bingo, that seems to be my issue. when setting https://git.b12f.io/pub-solar/os/src/branch/teutat3s-develop/flake.nix#L11 to
latest.url = "nixpkgs/nixos-unstable";
and after doing nix flake update the previous trace shows 0.5.0 as expected 🎉
| 13:53:35 |
| David Arnold (blaggacao) | Maybe you could make a PR to devos since that seems to be the generally better default 😂 | 14:04:28 |
| David Arnold (blaggacao) | I don't fully understand why it didn't use the default branch or maybe you had an "old" fetch and nix didn't bother to check for new commits? | 14:17:28 |
| David Arnold (blaggacao) | * I don't fully understand why it didn't use the default branch or maybe you had an "old" fetch of `master` and `nix` didn't bother to check for new commits? | 14:17:54 |
| @teutat3s:pub.solar | https://github.com/divnix/devos/pull/350 | 14:20:17 |
| @teutat3s:pub.solar | In reply to @blaggacao:matrix.org
I don't fully understand why it didn't use the default branch or maybe you had an "old" fetch of master and nix didn't bother to check for new commits? Sounds like a possible explanation, the locked commit was from the release-21.05 branch though | 14:21:16 |
| David Arnold (blaggacao) | Are the ancillary bumps in the flake.lock harmless? | 16:16:31 |
| David Arnold (blaggacao) | I usually update a specific input with nix flake lock --update-input <name>, but if they are harmless, I'd be fine with this bump. | 16:18:06 |
| David Arnold (blaggacao) | * I usually update a specific input with nix flake lock --update-input <name>, but if they have been at least summarily checked, I'd be fine with this bump. | 16:18:32 |
| @teutat3s:pub.solar | It builds fine for me - harmless upon first inspection I'd say | 16:21:09 |
| @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:matrix.org joined the room. | 20:30:32 |
| @d4hines:matrix.org | 👋 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:matrix.org | 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
Not sure if this faile reproducibly: https://github.com/divnix/devos/runs/3193959663 ? nix -Lv flake check
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.org
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. There'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 |
