| 8 Jun 2025 |
 emily | I wouldn't be surprised if it just breaks | 00:29:03 |
| emily | IIRC passing non-ASCII attribute names via the CLI might not work though | 00:29:09 |
 pveierland | No, just trying to confirm my understanding of the data model | 00:30:14 |
| emily | I suspect the answer is that it wasn't really thought about :) | 00:35:01 |
| emily | Nix string handling is sort of weird | 00:35:13 |
| pveierland | Cool, will try my best to accommodate byte strings then :) | 00:36:44 |
|  zitrone 🍋 joined the room. | 01:02:47 |
| pveierland | (Details in this crate were quite helpful to understand path encoding handling: https://docs.rs/gix-path/latest/gix_path/) | 02:00:45 |
| emily | I wouldn't recommend supporting non-UTF-8 attrpaths in tooling. | 12:57:08 |
| emily | you run into the "Makefile problem" (https://wiki.mercurial-scm.org/EncodingStrategy#The_.22makefile_problem.22) quickly – text has to be able to refer to paths | 12:57:37 |
| emily | see https://docs.rs/camino/latest/camino/ for a perspective on this as applied to file paths | 12:58:00 |
| emily | anyway, nix eval nixpkgs#é and nix eval nixpkgs#'"é"' both behave bizarrely (they interpret nixpkgs as a path for some reason), so I suspect ASCII is the only reliable thing | 12:59:00 |
| pveierland | I agree, it would be way easier to just do a possibly lossy conversion of all attrpaths and paths to UTF8, and it would probably result in fewer bugs overall + less code and specialized parsers etc | 13:50:15 |
| pveierland | Just trying to avoid losing any necessary representational ability | 13:51:09 |
