| 23 Oct 2024 |
 Leonardo Santiago | In reply to @o-santi:matrix.org
going to try today with latest commit again and see if this problem still persists. trace-function-calls is not available in current master either. Should I open an issue for this? | 13:48:03 |
| Leonardo Santiago | In reply to @roberthensing:matrix.org
Hi Leonardo Santiago , I'm using commit ed129267dcd7dd2cce48c09b17aefd6cfc488bcd in the nixops4 repo this was the commit I was using as well, but it was the one that prompted me to send this message as not all settings seem to be available | 13:50:28 |
| Leonardo Santiago | I'll try reverting even more to see if older commits still had all settings | 13:53:11 |
| Leonardo Santiago | In reply to @roberthensing:matrix.org
Maybe John Ericson has ideas for how the C API should be initialized to include libflakes functionality? I think there are 2 conflicting ideas for the C API, either it should be done through settings or through manual calling nix_libflake_init or something like that | 13:55:25 |
| Leonardo Santiago | In reply to @roberthensing:matrix.org
Maybe John Ericson has ideas for how the C API should be initialized to include libflakes functionality? * I think there are 2 conflicting ideas for the C API, either it should be done through settings or through manual calling nix_libflake_init | 13:55:54 |
| Leonardo Santiago | the one that seems to make the most sense is to call it automatically when the experimental feature is set with nix_setting_set but that is stateful and might lead to problems as there is no way to "unregister" the getFlake primop if another instance don't want those settings | 13:57:33 |
| Leonardo Santiago | of course, that is considering that per-instantiator settings configuration is something that the api is trying to allow | 13:58:07 |
| Leonardo Santiago | which seems to the case, given that it is trying to run away from using the same global config for all NixEvalState instances. | 14:01:52 |
 John Ericson | I was thinking of making a libflake subclass of the evaluator | 19:50:58 |
| John Ericson | Which would also help | 19:51:03 |
| Leonardo Santiago | But how would that work from an API standpoint? | 20:43:56 |
| Leonardo Santiago | * But how would that work from a C API standpoint? | 20:44:00 |
| Leonardo Santiago | If you set experimental-features="flakes" it would return a different EvalState instance with flakes enabled? | 20:44:55 |
|  Drewry Pope set a profile picture. | 20:48:33 |
| Leonardo Santiago set a profile picture. | 21:07:47 |
| Leonardo Santiago | * If you set experimental-features="flakes" it would return a different EvalState instance with flakes enabled? when calling 'nix_state_crate`? | 21:08:22 |
| Leonardo Santiago | * If you set experimental-features="flakes" it would return a different EvalState instance with flakes enabled? (when calling 'nix_state_crate`?) | 21:08:28 |
| Leonardo Santiago | * If you set experimental-features="flakes" it would return a different EvalState instance with flakes enabled? (when calling nix\_state\_crate\?) | 21:08:36 |
| Leonardo Santiago | * If you set experimental-features="flakes" it would return a different EvalState instance with flakes enabled? (when calling nix_state_crate\?) | 21:08:42 |
| Leonardo Santiago | * If you set experimental-features="flakes" it would return a different EvalState instance with flakes enabled? (when calling nix_state_create?) | 21:08:48 |
| 25 Oct 2024 |
|  @lholh:matrix.org joined the room. | 03:55:01 |
| Leonardo Santiago | what is the reasoning behind calling nix_value_force before returning the Value? I find this not only confusing but detrimental as it evaluates a lot more than needed most of the time. | 14:03:58 |
| Leonardo Santiago | I'm saying this because a builtins.getFlake "path" call is taking 20 seconds (even though it's local, not copying anything) and I can't trace it to anything other than it evaluating the packages outputs even though I'm not asking for it | 14:26:17 |
| Leonardo Santiago | I'm trying to setup a minimal example | 14:26:43 |
| Leonardo Santiago | yes, I can see it's evaluating outputs.packages.x86_64-linux.default by adding a builtins.trace to it, though it seems to be the only one being eagerly evaluated | 14:39:29 |
| Leonardo Santiago | forget about it, I was testing out flake-compat and in the end it adds
defaultNix =
(builtins.removeAttrs result ["__functor"])
// (if result ? defaultPackage.${system} then { default = result.defaultPackage.${system}; } else {})
// (if result ? packages.${system}.default then { default = result.packages.${system}.default; } else {});
and it was this result ? defaultPackage.${system} that was causing the attribute to be evaluated when importing. when using builtins.getFlake, this doesn't happen but the slowness comes from copying the whole directory to the store
| 18:09:52 |
| Leonardo Santiago | * forget about it, this is due to me testing out flake-compat and in the end it adds
defaultNix =
(builtins.removeAttrs result ["__functor"])
// (if result ? defaultPackage.${system} then { default = result.defaultPackage.${system}; } else {})
// (if result ? packages.${system}.default then { default = result.packages.${system}.default; } else {});
and it was this result ? defaultPackage.${system} that was causing the attribute to be evaluated when importing. when using builtins.getFlake, this doesn't happen but the slowness comes from copying the whole directory to the store
| 18:10:02 |
| Leonardo Santiago | * forget about it, this is due to me testing out flake-compat and in the end it calls
defaultNix =
(builtins.removeAttrs result ["__functor"])
// (if result ? defaultPackage.${system} then { default = result.defaultPackage.${system}; } else {})
// (if result ? packages.${system}.default then { default = result.packages.${system}.default; } else {});
and it was this result ? defaultPackage.${system} that was causing the attribute to be evaluated when importing. when using builtins.getFlake, this doesn't happen but the slowness comes from copying the whole directory to the store
| 18:10:07 |
