| 9 Nov 2021 |
 lovesegfault | Is it possible to have a structure like this with flakes:
foo
├── bar
│ └── flake.nix
├── baz
│ └── flake.nix
└── flake.nix
Where bar and baz's flakes use a lib attr exposed by the flake.nix in the parent foo dir?
| 18:37:35 |
| lovesegfault | When I try I get error: relative path '../' points outside of its parent's store path '/nix/store/yd4jpnk2l1axgmzzc3qbzdgryd2gdxsf-source' | 18:38:01 |
| lovesegfault | cc. Robert Hensing (roberth) who seems to have done some work on relpaths in flakes | 18:38:11 |
| lovesegfault | Inputs in the bar/baz flakes looks like this:
inputs = {
foo.url = "path:../";
};
| 18:38:41 |
| lovesegfault | Error from my actual project:
error: relative path '../' points outside of its parent's store path '/nix/store/yd4jpnk2l1axgmzzc3qbzdgryd2gdxsf-source'
… while fetching the input 'path:../'
… while updating the flake input 'genesis'
… while updating the lock file of flake 'git+file:///home/bemeurer/src/genesis?dir=voyager'
| 18:40:39 |
 Robert Hensing (roberth) | lovesegfault: relative paths are a bit underdeveloped. I did write this https://github.com/NixOS/nix/pull/5437 to fix "normal" relative paths support, but more work needs to be done to support .. | 18:40:48 |
| Robert Hensing (roberth) | right now relative paths are treated like a fetcher, thus ignoring the special nature of relative paths | 18:42:12 |
| lovesegfault | Interesting, so relpaths can only go "forward" into the directory structure? | 18:42:27 |
| Robert Hensing (roberth) | yes, that is a consequence of the current implementation | 18:42:38 |
| Robert Hensing (roberth) | inputs with relative paths should probably be represented by a storepath + subpath pair, (OT) similar to https://github.com/NixOS/nixpkgs/pull/112083 coincidentally | 18:44:27 |
| lovesegfault | I wonder if I can workaround this by abusing symlinks in my repo | 18:47:03 |
| Robert Hensing (roberth) | there's probably many ways this feature could be reimagined | 18:47:07 |
| lovesegfault | Another thing I find myself wanting is a way to share flake locks | 18:48:00 |
| lovesegfault | like, I have one repo with many flakes, but I want one shared lockfile | 18:48:15 |
| Robert Hensing (roberth) | I'd lean towards such a design for relative path flakes | 18:49:30 |
| Robert Hensing (roberth) | no lock file and no locking of the relative flake either | 18:50:01 |
| Robert Hensing (roberth) | i.e. don't fetch them, but use a subpath of self | 18:50:37 |
| lovesegfault | yup | 18:51:09 |
|  Roos left the room. | 18:51:31 |
 andi- | How would that handle building only a subflake? (think partial checkout) | 23:49:32 |
| 10 Nov 2021 |
|  Rickard Nilsson joined the room. | 11:22:12 |
 figsoda | In reply to @andi:kack.it
How would that handle building only a subflake? (think partial checkout) Is ?dir= what you want? | 13:50:09 |
| andi- | No I mean the situation that subflakes wont have a lockfile | 13:50:24 |
| 11 Nov 2021 |
|  Gogu de la Gazé joined the room. | 12:20:48 |
|  cafkafk set a profile picture. | 18:05:38 |
| 12 Nov 2021 |
|  NixOS Moderation Bot unbanned  matthewcroughan - nix.zone. | 00:23:30 |
| 14 Nov 2021 |
|  betaboon joined the room. | 11:19:13 |
| 15 Nov 2021 |
| Robert Hensing (roberth) | andi-: does it even support partial checkouts? I don't think we have to worry about it yet. Partial checkouts can be supported by adding checkout parameters to the top-level of the flake (next to inputs, outputs, description) where the checkout parameters can be read during locking, cached in the lock file and used when fetching. | 10:23:33 |
| andi- | I don't think it support any like that right now. I am mostly concerned about the situation where the flake isn't at the root of the repository and everything it should care about is living besides it (and not in the parent/sibling directories). | 10:24:27 |
| Robert Hensing (roberth) | so I think we don't need to be worried about it, because they're implementation concerns, not implementability concerns | 10:28:13 |
