 | Nix Hackers | 889 Members |
| For people hacking on the Nix package manager itself | 191 Servers |
| Nix Hackers | 889 Members |
| For people hacking on the Nix package manager itself | 191 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Apr 2025 | ||
 Ochoa left the room. | 21:30:18 | |
 jaen | I'm not sure if it's the best place to ask this, but I figured subflakes are new enough and not yet ironed out that it might as well be. I tried to play around with them with the latest nix to see how the situation has improved and I have two questions: a) should I expect subflakes to work without a git repo, or not? If lockfiles are already there it seems to keep working even if I drop the .git folder, but without it will fail to generate the lock file complaining about access to absolute path '/nix/store/flake.nix' is forbidden in pure evaluation mode for a subflake that refers to its parent,b) in another test I have a root flake, and two child flakes which are siblings. Both siblings refer to the parent, and one of the siblings refer to another, which results in a found circular import of flake for the root flake. Is this something that is not supposed work "by specification" or is it a consequence of https://github.com/NixOS/nix/issues/7730 not being resolved yet? I feel intuitively that this should work, but maybe there's something I missing that makes it impossible? | 22:07:11 |
 alexfmpe changed their profile picture. | 23:56:01 | |
| 20 Apr 2025 | ||
 orhosko joined the room. | 08:51:54 | |
 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 |
| 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 |