| 14 May 2024 |
samrose | soemthing like that anyway :) | 14:26:41 |
Lunaphied | If you imagine it working with recursive Nix you could just... use that, as it would do everything you needed basically. | 14:27:03 |
Qyriad | In reply to @lunaphied:lunaphied.me I wondered why it seemed so half baked given that RFC literally doesn't discuss how it'd be practically useful at all the talk at nixcon does | 14:27:07 |
Lunaphied | Nope | 14:27:11 |
Qyriad | it… doesn't? | 14:27:23 |
Lunaphied | It discusses it informally but not relating to the actual implementation | 14:27:35 |
Qyriad | ah | 14:27:42 |
Lunaphied | It's also a very short talk | 14:27:44 |
Lunaphied | Just an overview of the idea generically | 14:27:52 |
samrose | probably if someone is working on this in Lix, you could consider the ideas in that RFC, but you might end up coming up with something that does what you need, and may or may not use the approach in that rfc since it maybe only addresses part of the problem | 14:28:53 |
samrose | IMHO | 14:28:57 |
Lunaphied | I think it addresses enough to have some value; it's just not clear that other existing limitations (such as how quickly things can be added to the store) don't compromise its use. also the bug that required disabling basically the entire implementation still needs fixing | 14:30:01 |
samrose | I defer to you, because despite what I said above, you likely know much more than I on the topic | 14:30:45 |
samrose | but I will be interested to see what evolves in lix in any case around this stuff | 14:31:25 |
Lunaphied | We look forward to figuring out a more useful implementation that actually has like. Examples. lol | 14:32:11 |
raitobezarius | I actually have pseudo usecases of dyndrvs | 15:37:32 |
raitobezarius | But I don't know if they work with current implementation | 15:37:42 |
raitobezarius | My biggest interest is computing the rebuild closure for a package | 15:37:56 |
raitobezarius | So that you don't include aimlessly all the build dependencies you find and 2x your system closure | 15:38:14 |
samrose | raitobezarius: does it help to use the content addressed approach to derivations for what you are thinking? | 15:39:58 |
raitobezarius | Not really, you need to attach in the store the result of walking the useful build dependencies of a Nix drv closure I think? | 15:41:56 |
raitobezarius | It's orthogonal to CA mostly | 15:42:03 |
samrose | In reply to @raitobezarius:matrix.org Not really, you need to attach in the store the result of walking the useful build dependencies of a Nix drv closure I think? Useful means "what has changed" is that right, so that you can somehow skip what has not changed? | 15:44:28 |
raitobezarius | https://github.com/NixOS/nixpkgs/issues/180529 | 15:45:55 |
samrose | In reply to @raitobezarius:matrix.org https://github.com/NixOS/nixpkgs/issues/180529 Hmm yeah cool that seems to be where the ball was picked up and carried forward https://github.com/NixOS/nixpkgs/issues/180529#issuecomment-1772248566 and I will take the time to read this sometime soon LOL https://discourse.nixos.org/t/pre-rfc-implement-dependency-retrieval-primitive/43418/6 | 15:58:39 |
| kha13d joined the room. | 16:01:53 |
toastal-matrix-sucks | How to deal with attribute 'nix_2_19' missing for haskellModules? | 16:07:07 |
toastal-matrix-sucks | Is there a different overlay? Will there be missing features that break this? | 16:07:48 |
toastal-matrix-sucks | * How to deal with attribute 'nix_2_19' missing for haskell-modules? | 16:08:27 |
Qyriad | that's… odd, we shouldn't be touching 2.19? | 16:51:43 |