13 Jan 2022 |
@gytis-ivaskevicius:matrix.org | Do yeah, about all this | 19:43:54 |
@gytis-ivaskevicius:matrix.org | I had a thought | 19:43:57 |
@gytis-ivaskevicius:matrix.org | What if stuff like 'nix shell nixpkgs#gnome3.nautilus' were to point to 'subflake' named 'gnome3', package 'nautilus' | 19:45:09 |
@gytis-ivaskevicius:matrix.org | And su flakes should be able to reference each other | 19:45:41 |
@gytis-ivaskevicius:matrix.org | This way you could not only solve this issue but also gain improvements in terms of parallelism/memory usage/caching | 19:46:43 |
@gytis-ivaskevicius:matrix.org | Just a thought | 19:46:52 |
@gytis-ivaskevicius:matrix.org | Also possibly nix evaluation would no longer take 30gb of ram 😅 | 19:47:21 |
Pacman99 | Well I imagine that some of those subsystems could just get their own flake, like imagine if you could instead to github:nixos/gnome#nautilus | 21:26:16 |
Pacman99 | I think in general the vision is to eventually start removing stuff from nixpkgs, so those subsystems get their own flake and github repo to work with. Which is basically circling back to the pro/con monorepo debate. | 21:27:30 |
Pacman99 | * I think in general the vision is to eventually start removing stuff from nixpkgs, so those subsystems get their own flake and repo to work with. Which is basically circling back to the pro/con monorepo debate. | 21:27:40 |
14 Jan 2022 |
Pacman99 | @room I just made this to update the devos "In the Wild" section: https://github.com/divnix/devos/pull/416. I want to collect a lot of examples, so if anyone has a working repo that uses digga can you please add a suggestion to the PR, or make a PR of your own to add it. | 04:10:04 |
| @cw:kernelpanic.cafe changed their display name from Rev. CornWallace III (novus ordo seclorum) to coilWinder. | 04:40:44 |
| @cw:kernelpanic.cafe changed their display name from coilWinder to CoilWinder (novus ordo seclorum). | 04:42:51 |
David Arnold (blaggacao) | Gytis Ivaskevicius: digga is using a fork which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such automagics that can cause false positives? | 14:37:04 |
David Arnold (blaggacao) | * Gytis Ivaskevicius: digga is using a fork of FUP which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such automagics that can cause false positives? | 14:37:17 |
David Arnold (blaggacao) | * Gytis Ivaskevicius: digga is using a fork of FUP which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such automagics that can potentially cause hard-to-debug false positives? | 14:37:46 |
David Arnold (blaggacao) | In reply to @pachumicchu:myrdd.info I think the simplest reason is that it hurts the performance of nix search Yes, there is an elco's comment on the relevant nix PR that's the source of this wisdom. | 14:39:02 |
David Arnold (blaggacao) | In reply to @gytis-ivaskevicius:matrix.org This way you could not only solve this issue but also gain improvements in terms of parallelism/memory usage/caching At one point, not only entire flake evals are to be cached, but also individual function calls. If/when that happens, it also means fetchurl and derivatives are prohibitive within the flake body. | 14:40:25 |
David Arnold (blaggacao) | * Gytis Ivaskevicius: digga is using a fork of FUP which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such upstream automagics that can potentially cause hard-to-debug false positives? | 14:41:08 |
@gytis-ivaskevicius:matrix.org | In reply to @blaggacao:matrix.org Gytis Ivaskevicius: digga is using a fork of FUP which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such upstream automagics that can potentially cause hard-to-debug false positives? Sure, lets do it. | 15:03:57 |
@gytis-ivaskevicius:matrix.org | Lets go for 1 normal release and 1 breaking changes release like last time | 15:04:16 |
@gytis-ivaskevicius:matrix.org | In reply to @blaggacao:matrix.org At one point, not only entire flake evals are to be cached, but also individual function calls. If/when that happens, it also means fetchurl and derivatives are prohibitive within the flake body. yeah, but function calls arent cached between evaluations | 15:04:58 |
David Arnold (blaggacao) | In reply to @gytis-ivaskevicius:matrix.org yeah, but function calls arent cached between evaluations Afaik, not yet. But I had the impression that this is the long term goal of flakes. | 16:03:02 |
David Arnold (blaggacao) | I've been musing about using dqlite as a drop in for sqlite for a while now so to have distributed eval caches 😃 | 16:03:33 |
David Arnold (blaggacao) | One could think of eval-cache as the "compiled" version of a nix program. So why not distribute (content &/or input) addressed compiled code? 🤕😃 | 16:04:19 |
@gytis-ivaskevicius:matrix.org | Please elaborate? What's so special about dqlite and how it impacts anything? SQLite contains metadata about derivations only | 16:05:03 |
@gytis-ivaskevicius:matrix.org | Yeah, evaluating nix and sharing result as something along the lines of bison would make sense | 16:06:07 |
David Arnold (blaggacao) | dqlite uses raft to distribute state, so you could construct a mesh with peers (collegues or build servers), for all that is cached in sqlite. | 16:07:07 |
David Arnold (blaggacao) | Metadata only? I used to think it holds the eval cache. | 16:08:26 |
@gytis-ivaskevicius:matrix.org | I'm pretty sure it's just minimal metadata | 16:08:49 |