| 8 Aug 2023 |
 infinisil | Robert Hensing (roberth): John Ericson: Ping | 14:33:01 |
 John Ericson | sorry! On the west coast but was up in term, not sure how I missed the ping | 16:36:06 |
| John Ericson | I am not sure if I am reading https://discourse.nixos.org/t/2023-08-08-nixpkgs-architecture-team-meeting-42/31454 right on drvPath, but did we agree that regardless of who is deprecating what, it would be nice to have this builtin? | 22:18:22 |
| John Ericson | IMO saying Nixpkgs is blocked on Nix, and Nix is blocked on Nixpkgs is not the best state of affairs | 22:18:47 |
| John Ericson | the general approach Robert Hensing (roberth) and I have discussed is Nix and Nixpkgs being increasingly willing to do chart their own paths | 22:19:32 |
| John Ericson | I think the unit files is a good example of this, and decoupling "package from derivation" https://github.com/NixOS/nix/issues/6507 is also a good example | 22:20:22 |
 DavHau | The factor of 5-7 is correct for the current benchmark. Though, I expect the impact on real world use cases to be lower. One reason is that the module system does have defaults for each individual option, vs. the package func doesn't. Once more options are used, the ration should get lower. But this is just speculation.
For sure there is room for optimization.
Let's continue the discussion here: https://github.com/nixpkgs-architecture/issues/issues/22 | 22:22:28 |
| DavHau | Ok, I now re-ran the benchmark passing 100 env variables to each derivation. Now the result looks much better. The modules are between 1.6 to 2 times slower than pkg-funcs. | 22:42:13 |
| infinisil | John Ericson: We can't change drvPath behavior without breaking compatibility, which we shouldn't do for such a core part. So the only alternative is to slowly deprecate it by introducing another say drvPathNew that doesn't have the problem. But it doesn't make sense to do that in Nixpkgs, because drvPath is effectively exclusively used by Nix itself. In addition it's Nix itself that produces drvPath in the first place, it should really be Nix's responsibility to deprecate or fix it. | 23:13:44 |
| infinisil | The idea of keeping Nix stable and changing Nixpkgs instead only really works for things like wrappers of builtin functionality that people are using instead, such as stdenv.mkDerivation | 23:18:07 |
| infinisil | Yes Nix doesn't have a good way to deprecate things yet, but that isn't Nixpkgs' problem :) | 23:23:15 |
| infinisil | * Yes Nix doesn't have a good way to deprecate things yet, but that isn't Nixpkgs' problem :) | 23:23:31 |
| 9 Aug 2023 |
| John Ericson | infinisil I think there is a misunderstanding of what is affected by this change. "Regular" usage that treats the output of `builtins.derivation` as a black box is not affected. Only usage that explicitly pulls out `drvPath` and splices that (into strings, ultimately into another derivation) is affected. Only *user* code does this. | 01:54:54 |
| infinisil | Yeah I get that, still, it's a breaking change | 01:56:47 |
| John Ericson | I believe based on my recollection of experiments, nix in fact hardly cares what the contents of `drvPath` is. It might just check that there is a string with that key. | 01:58:01 |
| John Ericson | It is a breaking change, but it's Nixpkgs's breaking change | 01:58:17 |
| John Ericson | Robert Hensing (roberth)'s issue from a "nuts and bolts" perspective is to decouple what `derivation` produces from what the CLI or anything else expects | 01:59:15 |
| John Ericson | Right now those things sort of match up, but it's somewhat a coincidence that they do | 01:59:51 |
| John Ericson | We've been considering not doing deprecation cycles individual fields, but like a `derivationSuperStrict` that | 02:00:51 |
| John Ericson | * We've been considering not doing deprecation cycles individual fields, but like a `derivationSuperStrict` | 02:00:58 |
| infinisil | Really not sure why that should concern Nixpkgs though | 02:01:26 |
| John Ericson | And behind that is allowing individual projects to pick and choose their own stability / manage their own deprecation cycle | 02:01:37 |
| John Ericson | With Nix just saying "here's what I produce, here's what I expect, between those is a lot of flexibility you do what you want" | 02:02:08 |
| John Ericson | Also, a nix-based deprecation cycle means the same version of Nixpkgs evaluated with different Nixes gives different stuff (baring more language version machiner) | 02:04:09 |
| infinisil | I really only care about not having breaking changes without warning | 02:04:27 |
| infinisil | In Nixpkgs (but Nix should care about that too) | 02:04:49 |
| John Ericson | I have 0 problem with Nixpkgs choosing to introduce a new attribute :) | 02:04:56 |
| John Ericson | Doing the warnings, etc. | 02:05:18 |
| infinisil | In reply to @Ericson2314:matrix.org
Also, a nix-based deprecation cycle means the same version of Nixpkgs evaluated with different Nixes gives different stuff (baring more language version machiner) There's minver.nix for that | 02:05:26 |
| infinisil | In reply to @Ericson2314:matrix.org
I have 0 problem with Nixpkgs choosing to introduce a new attribute :) The problem is that Nix itself continues using drvPath. There needs to be an alternative that doesn't make everybody have warnings when they use e.g. the nix repl to evaluate derivations | 02:07:09 |
