Conversation
|
LGTM, can you add some documentation about this to |
I don't think this changes the way any program would behave, but it's a cleaner internal representation.
|
The failure on ubuntu seems to be due to some unrelated issue with recursive nix and network connection? I could be misinterpreting that though. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
Note that this assertion in the docs is wrong:
The This is actually how my https://github.com/cstrahan/tree-sitter-nix grammar parses this as well, so I don't really mind -- I think it's a reasonable parse, after all. I think it makes sense that the second I discovered this while adding another test case (inspired by the docs): turns out, the actual parse looks like: |
|
@cstrahan Oh, you're totally right. It doesn't get parsed as a single path, but it also does not get parsed as a division. I'm not sure exactly how to clarify that in the docs without introducing more confusion. Unfortunately, I think what makes the most sense is indeed to parse - Antiquotation is supported in any paths except those in angle brackets.
- `./${foo}-${bar}.nix` is a more convenient way of writing
- `./. + "/" + foo + "-" + bar + ".nix"` or `./. + "/${foo}-${bar}.nix"`. At
- least one slash must appear *before* any antiquotations for this to be
- recognized as a path. `a.${foo}/b.${bar}` is a syntactically valid division
- operation. `./a.${foo}/b.${bar}` is a path.
+ Antiquotation is supported in any paths except those in angle brackets.
+ `./${foo}-${bar}.nix` is a more convenient way of writing
+ `./. + "/" + foo + "-" + bar + ".nix"` or `./. + "/${foo}-${bar}.nix"`. At
+ least one slash must appear *before* any antiquotations for this to be
+ recognized as a path. For backward compatibility, `a.${foo}/bar` is
+ parsed as `a.${foo}` applied to the path `/bar`. To make a single path,
+ you can always prepend a slash: `/a.${foo}/bar`. |
Based on <NixOS#5066>. Change-Id: I28757321e19e51a2d9fa1df85897e67eee63aabe Reviewed-on: https://cl.tvl.fyi/c/depot/+/13922 Autosubmit: sterni <[email protected]> Reviewed-by: tazjin <[email protected]> Tested-by: BuildkiteCI
From <NixOS#5066>. Change-Id: I165a6a8301363fca0e25162786914ef989032e62 Reviewed-on: https://cl.tvl.fyi/c/depot/+/13923 Autosubmit: sterni <[email protected]> Tested-by: BuildkiteCI Reviewed-by: tazjin <[email protected]>
I don't think this changes the way any program would behave, but it's a cleaner internal representation. From <NixOS#5066>. Change-Id: Ifd8c4346b478b06f11e7cd27b89eba975d2a8b9e Reviewed-on: https://cl.tvl.fyi/c/depot/+/13924 Tested-by: BuildkiteCI Autosubmit: sterni <[email protected]> Reviewed-by: tazjin <[email protected]>
4 participants
This enables you to write something like
Without this one has to write
Which is less ergonomic. The other intuitive approaches
and
Are semantically different, and usually not what one wants. Adding this syntax provides an obvious, and usually correct way of accessing paths that depend on a variable.
This also affects HPATHs e.g.
~/${foo}/barIt does not affect SPATHs e.g.
<nixpkgs/${foo}>is not valid, even with this PR.I couldn't figure out any way to do SPATHs without changing the lex of things like
3<a.${foo}, which is currently a valid lex. In theory anything that ends in>would be an error anyways, but in order to find that out one needs to parse the whole expression, including arbitrary nix code in the antiquotation. Given that flakes don't support SPATHs anyways, this seems like a minor sacrifice.This change shouldn't affect anything that currently passes the lexer. All the tests pass without modification, and the generated nixpkgs derivations are identical.