 | Nix Hackers | 899 Members |
| For people hacking on the Nix package manager itself | 188 Servers |
| Nix Hackers | 899 Members |
| For people hacking on the Nix package manager itself | 188 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Apr 2025 | ||
 alexfmpe changed their profile picture. | 23:56:01 | |
| 20 Apr 2025 | ||
 orhosko joined the room. | 08:51:54 | |
 Robert Hensing (roberth) | a: Relative path flakes are an incremental improvement. They create a new relation, between a flake and a "parent" whose source it is relative to. The source of a path flake (ie non-git) is currently always the directory of the flake in isolation, so inputs can only refer to subdirectories.This could be improved by parsing the flake.nix in the context of the whole file system first, figure out the locations of the closure of path inputs, and use those. I don't think we can treat them similarly to git flakes though, because that would mean taking the most specific common ancestor directory as the only "parent source" for all path inputs, which will include things like ~/src or /. That's not feasible with the current flake to store path copying solution, but even after we fix that, it would not be checking any kind of hermeticity. I think the property we want is that the knowing the inputs closure is sufficient to know which files are available to evaluation, and such a single source wouldn't provide much info.Instead, we could import these flakes individually and by default disallow any "implicit", non- inputs parent references like "${readFile ../version.txt}". These could be re-allowed with an explicit parent = ../.; field in the flake.nix top level attrset. This is more explicit/hermetic and makes the eval cache more effective by ignoring changes in unrelated sibling directories.We could prototype this approach by implementing it for path inputs first and harmonizing the other flake input types with it afterwards. | 11:54:20 |
| Robert Hensing (roberth) | b: IIRC there was some long hanging fruit possibly without 7730, but reusing input lock files would solve adjacent issues | 11:55:54 |
 jaen | Robert Hensing (roberth): hmm, I assumed that you can't reach across subflakes without going through the inputs, is that not true? It's why I thought you could just find all Anyway thanks for response — it seems that subflakes are not quite ready for more complex use-cases yet, I'll guess I'll do something simpler for now and watch issue 7730 for updates, so I can at least help with testing. | 15:33:16 |
 tomberek | I have explored a concept before where a flake could be composed of multiple sub-components that had inter-related inputs. It is different from what are normally called sub-flakes, but I think is closer to what people are expecting them to be. I called it "crystals" and the initial proof-of-concept was a relatively simple matter of searching through a source tree for all crystal.nix files and merging their inputs into the root's lockfile: https://github.com/flox/nix/commit/8a684bdee6009e6375e855ed79bb9c532dae805c . | 16:50:24 |
| tomberek | Inputs would "bubble-up" into the root lockfile to store a canonical lock, and also "bubble-down" as inputs available for each sub-crystal to use. | 16:51:59 |
| 21 Apr 2025 | ||
 Las | there really needs to be better docs on how to calculate placeholder paths | 12:50:36 |
 flokli | In reply to @Las:matrix.orghttps://snix.dev/rustdoc/src/nix_compat/store_path/utils.rs.html#205-209 | 17:38:22 |
| Las | is this for CA too? | 17:38:51 |
| flokli | No idea | 17:40:31 |
 Martin Schwaighofer | In reply to @Las:matrix.orgThis helped me implementing the CA ones: https://github.com/puckipedia/tarnix/blob/canon/ca-placeholder.nix | 17:45:14 |
| Las | this is cursed | 17:46:42 |
 puck | ^_^ | 19:14:37 |
| puck | most of the logic in that file is to properly adjust stringLength output to the post-substitution paths, even, the actual logic there is like three lines | 19:18:01 |
| 22 Apr 2025 | ||
| jaen | In reply to @tomberek:matrix.orgInteresting, but I think this loses the useful property of scoping inputs to some subflake, such as development inputs. For this to be equivalent, I think it would have to have some concept of development (name to be biskeshed) inputs that are only fetched if actually used (e.g. a devshell using them is entered or something). Not sure how much more complex this would have made the implementation. | 07:01:37 |
| flokli | This is the dependencies / devDependencies problem, and whether to transitively propagate dev dependencies inputs | 10:06:56 |
| flokli | I'm not sure there's been some scoping out around this yet, but it's one of the issues with the current design. | 10:13:23 |
 sterni (he/him) | Any ideas what change this could be related to? Is this a bug or where there conscious changes to restrict-eval? I looked at the changelogs but nothing jumped out to me (maybe the relative flake change?) https://github.com/NixOS/nixpkgs/issues/400784 | 10:15:13 |
 dramforever | can you try nix-shell -i bash -p coreutils jq nix -I nixpkgs=.? | 10:59:59 |
| dramforever | * can you try nix-shell -p coreutils jq nix -I nixpkgs=.? | 11:00:16 |
| dramforever | sorry, edited | 11:00:21 |
| sterni (he/him) | sure, that works fine | 11:01:17 |
| dramforever | and then also bash {that script} | 11:01:22 |
| dramforever | but with the dependencies in $PATH | 11:01:35 |
| dramforever | in like nix shell or something | 11:02:27 |
| dramforever | well, it's supposed to fail pretty fast right? if so i can't reproduce this problem | 11:04:14 |
| dramforever | i'm on aca270648eca which is latest master of writing | 11:06:18 |
| sterni (he/him) | hmm I can with nix-instantiate --eval --option restrict-eval true -I . ./maintainers/scripts/haskell/transitive-broken-packages.nix on current master | 11:08:40 |
| sterni (he/him) | it's possible that it's because of a daemon / frontend version mismatch then | 11:09:10 |