"Nix Pointer"

[roberth]

Is your feature request related to a problem?

We tend to use attribute paths to refer to attributes, like packages.x86_64-linux.default, and we do so in the expression language, but also outside of it with an ad hoc syntax. Problems:

• The ad hoc attribute path syntax has not been formalized.
  • It's unclear how a different tool should parse it.
  • It's unclear how a different tool should generate it.
  • It may be unclear whether it embeds verbatim into other syntaxes (e.g. can it contain a %?). I assume all symbols are valid and escaping attribute paths in URLs etc should always be done.
• We don't have C++ functions for parsing or generating this format.
• It's undocumented and it doesn't have a name.
• It can't access list items

Proposed solution

Formalize "Nix Pointer", analogous to JSON pointer, but with a syntax that aligns with our conventions.

• no / but . for selection (breaking from JSON pointer and XPointer)
• Nix expression language-compatible quoting for attribute names
• Attribute-only Nix pointers are valid select-expressions when prefixed with the string v.

Alternative solutions

Additional context

We may want to bring a syntax for list selection into the Nix expression language so that all Nix pointers are valid expressions when prefixed with v. or some similar rule.

• [RFC 0181] List index syntax rfcs#181

Checklist

• checked latest Nix manual (source)
• checked open feature issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[Lassulus]

the main reason we wrote https://github.com/clan-lol/nix-select was that the nix language is quite limited (but it doesn't have to be). We would be very happy if the builtin selection language inside nix could take some (or all?) of the features from nix-select :)

[roberth]

That's more like a query language, like XPath or jq. Those return multiple results, whereas a "pointer" language only returns one value. I've opened #13146 for this.

The pointer language could be a subset of the query language, and be suitable for things like single installable fragments on the command line.

[Lassulus]

I'm not sure the single value is the main difference, as selecting an attrset would return that attrset and the query language would also return one, although it is constructed based on the query. so the pointer language would only return subtrees of the root attrset, instead of the query language which can construct new ones by merging subsets.

I guess the pointer specification is what can be used in attrset definitons though? but I'm not sure the list index syntax would make sense there. since assigning a list value != 0 the preceding values in the list would be unspecified? example:

{
  x.1 = "hello world";
} 

not sure what x.0 should return here?

so maybe this is another subset of the language?

[roberth]

The pointer language is, in my mind, more of a CLI thing, a better --attr or a properly specified installable after-# syntax.

---

{
  x.1 = "hello world";
}

so maybe this is another subset of the language?

It wouldn't be part of the syntax for literals, but potentially (NixOS/rfcs#181) we could have:

hello = x.1.world;

That's if we can take care of the let x = "x"; in [ x.1 ] "ambiguity" gracefully.