Nix Flakes | 878 Members | |
| 180 Servers |
| Sender | Message | Time |
|---|---|---|
| 21 Mar 2025 | ||
| I am not proposing one; I am complaining that the current choice (of making it look like it's "just a Nix file" was the wrong one. I do not have any specific opinions about what alternative name or extension or whatever should be used, as long as it does not have that problem | 16:52:11 | |
| And since it's a strict subset, I don't see a problem | 16:52:19 | |
| * I am not proposing one; I am complaining that the current choice (of making it look like it's "just a Nix file") was the wrong one. I do not have any specific opinions about what alternative name or extension or whatever should be used, as long as it does not have that problem | 16:52:19 | |
| because this introduces an additional footgun and we already have more than enough of thosed | 16:52:29 | |
| I expect .nix files to contain nix. A condition that is fulfilled with flake.nix files | 16:52:34 | |
| * because this introduces an additional footgun and we already have more than enough of those | 16:52:34 | |
| I don't expect arbitrary files to contain arbitrary values it's not like you have this compaint about NixOS Modules | 16:53:01 | |
| it means that you cannot expect either a) your usual code organization techniques or b) your existing code snippets to work as-is in a flake.nix because there is a subset of valid Nix that is invalid in a flake.nix | 16:53:22 | |
| ? | 16:53:50 | |
| There is an obivous freeform value place where you can write all the nix you want | 16:54:23 | |
| * There is an obvious freeform value place where you can write all the nix you want | 16:54:30 | |
| this is not relevant to my complaint | 16:54:50 | |
| "things should be the thing that they look like" is a pretty elementary principle of designing usable software and this violates that principle | 16:55:16 | |
| it looks like a freeform .nix file but apparently isn't one, in that there are additional syntactic restrictions (ie. beyond the semantic restrictions that might be imposed by some other code that the result of a .nix file may be fed into, and which are within expectations) | 16:56:03 | |
| I'm sure there are a hundred ways to work around this but the point is that you shouldn't need to, it should either a) work the same as everywhere else, or b) if that is not possible, make it obvious that it doesn't in some way | 16:56:45 | |
| (and the canonical way to denote different formats in most computer systems is... to use a different extension or variant of the standard extension) | 16:58:47 | |
| I believe that the opposite design decision has worse developer UX due to more footguns in unrestricted nix that may manifest during inputs outputs resolution Additionally, all .nix files are still fully syntactically valid nix files, which is the pre-condition that most tools expect. It's just the fact that some Now can you tell me again in plain words what you are complaining about "things should be the thing that they look like" is either fulfilled or much too vague | 17:04:47 | |
| * I believe that the opposite design decision has worse developer UX due to more footguns in unrestricted nix that may manifest during inputs outputs resolution Additionally, all .nix files are still fully syntactically valid nix files, which is the pre-condition that most tools expect. It's just the fact that some Now can you tell me again in plain words what you are complaining about. | 17:05:00 | |
so what does "not accepted by nix flake tooling" mean here exactly? you said there were additional 'syntactic restrictions' but this does not sound like that | 17:06:21 | |
Which behaves exactly as expected | 17:07:39 | |
5 is not a valid flake.nix even though it's a completely valid .nix file | 17:08:21 | |
| ... okay, so that doesn't look like a syntactic restriction to me at all, just a typecheck on a value | 17:08:21 | |
| in which case my complaint doesn't apply as stated | 17:08:56 | |
| No this is a syntactic check. With
Which tells us that this is not "just a typecheck on a value" | 17:10:17 | |
| I think in the case that one can do eta-expansion, one may want to loosen the restriction (assume the user does not destructure the args) | 17:11:23 | |
| in which case my complaint does apply | 17:12:38 | |