| 10 Jan 2024 |
9999years | that's... what i was asking for? | 17:57:13 |
K900 | It matches paths that lead to derivations | 17:57:25 |
9999years | the attrset names are what i need to type when i write definitions, so that's not very useful in a lot of cases | 17:57:47 |
K900 | I mean specifically package sets that are not packages | 17:58:18 |
K900 | Like haskellPackages | 17:58:21 |
9999years | yeah, i know. i'm saying that i need to be able to search for package sets as well as packages themselves | 17:58:44 |
K900 | If you e.g. nix search nixpkgs django, it'll show you python3Packages.django | 17:58:50 |
9999years | nix search nixpkgs turtle doesn't show me haskellPackages.turtle unfortunately... | 17:59:49 |
K900 | It's possible haskellPackages is explicitly excluded | 17:59:58 |
K900 | I'm not sure | 18:00:01 |
9999years | i think that's probably because haskellPackages is marked as dontRecurseIntoAttrs or whatever? but that sucks | 18:00:05 |
K900 | Yes | 18:00:15 |
9999years | like, instead of nixpkgs choosing some package sets that are "worth searching", it would be nice if i could choose which package sets to search | 18:00:34 |
9999years | it's just a bad user experience -- it's unreliable, so it's hard to trust and integrate into my workflow | 18:00:55 |
K900 | It's honestly mostly an eval time concern and the way to fix it is to fix our eval times | 18:01:03 |
9999years | eval times are part of it, but not the whole picture -- when i'm not searching for a python package, it's really annoying to see a bunch of results from pip. users should be able to choose which package sets to search | 18:02:22 |
9999years | do we expose anything autocomplete-like either? something where you can ask "what attribute names are acceptable with this prefix" | 18:02:45 |
K900 | Most commands have shell autocomplete for that | 18:03:09 |