| 9 Nov 2021 |
 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 |
| andi- | Well of course it can be implemented but it also has to be considered. That is why I am raising it (again and again). I'd love to move some of my monorepos to flakes eventually but adding 20GiB of binary assets to the store isn't a great selling point :-) | 10:43:25 |
| 17 Nov 2021 |
|  SkamDart joined the room. | 00:05:01 |
| 18 Nov 2021 |
|  scotttrinh joined the room. | 14:53:32 |
