| 28 Sep 2021 |
 @gytis-ivaskevicius:matrix.org | there is no way to define custom arguments like dir | 16:10:38 |
 yusdacra | In reply to @gytis-ivaskevicius:matrix.org
Not perfect, also I am not sure how I feel about file being editable AND automagically modifiable Isn't the point of a lockfile to not be modified? | 16:24:16 |
| yusdacra | In reply to @gytis-ivaskevicius:matrix.org
Not perfect, also I am not sure how I feel about file being editable AND automagically modifiable * Isn't the point of a lockfile to not be modified manually? | 16:24:52 |
| @gytis-ivaskevicius:matrix.org | what we are thinking of is not just a lockfile | 16:25:04 |
| @gytis-ivaskevicius:matrix.org | a file that would act as a lockfile AND inputs definition | 16:25:16 |
| @gytis-ivaskevicius:matrix.org | so you could avoid defining inputs in flake.nix | 16:25:27 |
| @gytis-ivaskevicius:matrix.org | and the whole avoidance of defining inputs in flake.nix is due to its limitations | 16:26:00 |
| yusdacra | Ah so basically to avoid redefining inputs in both places | 16:29:06 |
| yusdacra | That sounds like it'd be interesting | 16:29:39 |
| yusdacra | How would you "lock" an input to a certain revision in the example TOML? With flake.nix you can specify the revision in flake.nix and it will be locked, but if you change the rev field here doing a nix flake update would still update it right? | 16:31:43 |
| yusdacra | * How would you lock an input to a certain revision in the example TOML? With flake.nix you can specify the revision in flake.nix and it will be locked, but if you change the rev field here doing a nix flake update would still update it right? | 16:31:51 |
 @timdeh:matrix.org | I was imagining that the inputs in flake.nix are kinda redundant and that cli args could just as easily and remove and modify the lock file directly. So instead of inputs.someflake.url = "github:yada/yada" in the flake.nix you could do something like `nix flake add someflake github:yara/yada" | 17:59:41 |
| @timdeh:matrix.org | * I was imagining that the inputs in flake.nix are kinda redundant and that cli args could just as easily add, remove and modify the lock file directly. So instead of inputs.someflake.url = "github:yada/yada" in the flake.nix you could do something like `nix flake add someflake github:yara/yada" | 17:59:56 |
| @timdeh:matrix.org | * I was imagining that the inputs in flake.nix are kinda redundant and that cli args could just as easily add, remove and modify the lock file directly. So instead of inputs.someflake.url = "github:yada/yada" in the flake.nix you could do something like nix flake add someflake github:yara/yada" | 18:00:05 |
| yusdacra | hmm i see | 18:10:49 |
| yusdacra | That sounds nice TBH | 18:11:32 |
| @gytis-ivaskevicius:matrix.org | In reply to @timdeh:matrix.org
I was imagining that the inputs in flake.nix are kinda redundant and that cli args could just as easily add, remove and modify the lock file directly. So instead of inputs.someflake.url = "github:yada/yada" in the flake.nix you could do something like nix flake add someflake github:yara/yada" I'd rather have inputs explicitly defined in some file instead of such lock file editing | 18:43:07 |
| @gytis-ivaskevicius:matrix.org | but that might be just me | 18:43:12 |
| @timdeh:matrix.org | for what purpose though? If you could have a command list them out nicely, you can view the lockfile manually, and you can even explore the inputs in a repl. What does the explicit listing give us? | 18:44:12 |
| @gytis-ivaskevicius:matrix.org | I definetelly realize that something like nix flake show could show us all the inputs or even how they follow each other, its just that i would prefer it being managed declaratively | 18:53:36 |
 Pacman99 | To me the advantage is readability and clarity. When I look at someone else's flake online I can see what they depend on immediately. The lockfile and json in general is harder to read. | 18:53:39 |
| @gytis-ivaskevicius:matrix.org | just a personal preference | 18:53:42 |
| @gytis-ivaskevicius:matrix.org | to be fair you probably dont care all that much when it comes to inputs of some random flakes | 18:54:17 |
| @gytis-ivaskevicius:matrix.org | or atleast I dont | 18:54:24 |
| Pacman99 | And yeah you can def just use nix flake show, but I feel like you should be able to get a summary of the flake without the nix cli | 18:54:35 |
| @gytis-ivaskevicius:matrix.org | also not sure if you guys noticed, but the thing I wrote with toml does not contain any subflakes or anything. I was writing it with RFC92 in mind.
Its more of an idea, might be cool in the future | 18:57:07 |
 @kraftnix:matrix.org | In reply to @pachumicchu:myrdd.info
To me the advantage is readability and clarity. When I look at someone else's flake online I can see what they depend on immediately. The lockfile and json in general is harder to read. i agree, if i had to have access to a cli just to read the inputs of a flake that would massively reduce readability for me. especially when inspecting new projects, i dont always have a laptop with me.
i quite like the separation of concerns between definition of inputs and locking of revision that is currently provided by flake + lock | 21:11:59 |
| @timdeh:matrix.org | I wouldn't mind a hybrid approach either. Adding declarative inputs via the cli when convenient | 21:21:33 |
| @timdeh:matrix.org | * I wouldn't mind a hybrid approach either. Adding declarative inputs via the cli when convenient (which are then written to some inputs file, or just the existing flake.nix) | 21:21:55 |
| @kraftnix:matrix.org | one thing i did find very strange was the "hidden" interaction of the lockfile.
i.e. not having an input defined in flake.nix (or inputs of inputs), but having it defined in flake.lock (because it used to exist) and having that lockfile forever lock on a specific version. the UX of that felt very strange and expected, i would have rathered a more explicit error or warning as i had an old input (nur) for 3 months before it threw an error for a different reason which made me realise this behaviour even existed. | 21:28:01 |
