Sender | Message | Time |
---|---|---|
21 Mar 2025 | ||
? | 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 | |
. | 17:12:51 | |
it doesn't matter that you can technically still evaluate flake.nix via Nix directly and have it evaluate, because that has no bearing on how people actually use flake.nix files. what matters is that people cannot use "the way they write Nix files" for a flake.nix and expect it to work for its intended purpose, namely via nix flake evaluation | 17:13:39 | |
because, with additional syntactic restrictions, it is not actually the same format | 17:14:04 | |
if it were, you would be able to have a flake.nix that's just import ./actual-flake.nix where actual-flake.nix contains a valid flake | 17:14:26 | |
* if it were, you would be able to have a flake.nix that's just import ./actual-flake.nix where actual-flake.nix contains a valid flake (after all, the evaluated value would be identical) | 17:16:37 | |
Download hqdefault.jpg | 17:18:05 | |
okay, I guess this is where I stop bothering to put effort into an explanation then. | 17:18:39 | |
you do you. | 17:18:48 | |
22 Mar 2025 | ||
https://github.com/NixOS/nix/issues/4945 fwiw | 00:31:08 | |
00:42:31 | ||
21:25:44 | ||
23 Mar 2025 | ||
00:21:10 |