| 26 Aug 2021 |
 Las | Does anyone know why Recursive Nix is experimental? | 08:58:54 |
 Gytis Ivaskevicius | prob due to RFC 92 | 17:06:45 |
| Gytis Ivaskevicius | it implements similar feature but it all is approached differently | 17:07:04 |
 tomberek | (i could be wrong here) I think there is an issue about being in a build, and then starting another one which blocks the original build until the internal one completes. | 17:07:56 |
| tomberek | If you have overuse of recursive nix, this means you will have long chains of blocked builds. This is compared to the normal situation where a dependency can complete, tear down the sandbox, store results into cache, etc, and then start the next build whenever you want. | 17:09:29 |
| tomberek | My mental model for this is similar to "tail-recursion optimization". That if you know that the recursion is a tail call, you can do avoid blowing up the stack by turning a function call into a jump. Recursive-nix allows for arbitrary recursion, RFC92 tries to enforce the "tail-call" style. | 17:11:56 |
| tomberek | * My mental model for this is similar to "tail call optimization". That if you know that the recursion is a tail call, you can do avoid blowing up the stack by turning a function call into a jump. Recursive-nix allows for arbitrary recursion, RFC92 tries to enforce the "tail-call" style. | 17:12:23 |
| Gytis Ivaskevicius | Not sure if thats how i'd call it. I'd say its more of a build scheduling | 17:13:51 |
| Gytis Ivaskevicius | may need to read it again | 17:13:57 |
 sterni | In reply to @gytis-ivaskevicius:matrix.org
prob due to RFC 92 RFC 92 depends on recursive nix (albeit a more limited variant of it) | 17:48:20 |
| Gytis Ivaskevicius | In reply to @sternenseemann:systemli.org
RFC 92 depends on recursive nix (albeit a more limited variant of it) yeah, John Ericson idea is "STOP WRITING SHIT CODE!!!!" :D | 17:51:32 |
| Gytis Ivaskevicius | (sorry for the ping) | 17:51:42 |
| Gytis Ivaskevicius | (Actually I'd love to hear some update on all that 😉 ) | 17:52:32 |
 John Ericson | :) | 17:52:47 |
| John Ericson | Only news is we need more people to sign up to be shepherds | 17:54:22 |
| Gytis Ivaskevicius | I'm afraid its too big brain for me | 17:55:10 |
| tomberek | btw: i took a brief stab at updating the eelco commit into the new approach of DerivationTypes, but i started wading in areas of code I think John would be 10x faster than me on. | 17:55:25 |
| tomberek | * btw: i took a brief stab at updating the eelco commit into the new approach of DerivationTypes, but i started wading in areas of code I think John would be 10x faster than me on. (sorry, wrong topic: this was for "impure derivations") | 17:56:31 |
| Gytis Ivaskevicius | If anyone wishes to nominate themselves: https://github.com/NixOS/rfcs/pull/92 | 17:57:07 |
| Gytis Ivaskevicius | Also not related but nomination or two would be nice here as well 😀 https://github.com/NixOS/rfcs/pull/95 | 17:57:37 |
| John Ericson | Gytis Ivaskevicius feel free to bow out, but do note the first thing I would do in such meetings is try to explain the thing and make things clearer — not go straight into to deciding what we want to do with it. | 18:02:02 |
| sterni | John Ericson: btw I noticed today that string context can't track dependencies on just derivations via string context without any outputs, I feel like that would be a required change for your thing to work | 18:03:00 |
| sterni | i. e. context { "/my.drv" = { outputs = []; }; } is just reduced to context { } | 18:03:34 |
| sterni | wait path = true maybe it works | 18:04:07 |
| sterni | nvm | 18:04:37 |
| tomberek | Not sure where to post this, but i thought here would be good:
I've often wished for being able to chop up a mkDerivation into individual phases as derivations. Something like this would create more derivations, but they would be snapshot'd between phases. Eventually you can do something like filterSource on the configurePhase such that it doesn't have to be re-run for most changes to upstream.
chopIntoPhases = drv:
patchPhase = ... # drv built until patchPhase completes
configurePhase = ... # derivation that depends on "patchPhase" and performs a configurePhase"
... and so on
| 18:11:15 |
| Gytis Ivaskevicius | I gave it some thought a while back and I feel like there are better alternatives. What usecases do you have in mind? | 18:14:05 |
| Gytis Ivaskevicius | The real solution here is some sort of posix pipe with Nix which would allow to snapshot /build | 18:14:46 |
| tomberek | One would be when iterating on tests. No need to re-do a very expensive compilePhase. | 18:14:55 |
| tomberek | There are some packages for which the configurePhase is more expensive than anything else | 18:15:18 |
