| 8 Aug 2023 |
 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 |
| John Ericson | Warnings from forcing the old attribute? | 02:07:52 |
| John Ericson | Fair enough, if so | 02:08:09 |
| infinisil | Yeah nix repl at least uses drvPath to print, I imagine drvPath is used in other parts of Nix too | 02:08:54 |
| John Ericson | I guess it would be nice to say we can make use of this builtin irrespective of any deprecation policy: we can make a nicer way to keep this weird expressive power | 02:09:24 |
| John Ericson | The discard way is quasi unsafe because it "weakens" the string context throwing stuff away | 02:09:46 |
| infinisil | It's very late here, can you write a concrete proposal for Nixpkgs into some issue? We can take another look then | 02:09:57 |
| John Ericson | The one I made "strengthens" the string context so I think we can just set aside `drvPath` an hope this is good primop which we can e.g. make a Nixpkgs lib function from which would hide some of the details | 02:10:42 |
| John Ericson | Yeah | 02:10:47 |
