| 9 Jan 2024 |
infinisil | * Philip Taron (UTC-8): Oh yeah, I think for now it's fine, but if the tool becomes e.g. more generic (handling all of Nixpkgs) or much more complex, this could be revisited | 22:41:53 |
Philip Taron (UTC-8) | As currently structured it's a recipe for merge conflicts, for sure. | 22:41:54 |
Philip Taron (UTC-8) | See the Rust folks talking about this issue: https://github.com/rust-lang/lang-team/issues/122#issuecomment-964459769 | 22:43:15 |
| 10 Jan 2024 |
9999years |
Nix has a namespace problem. Versions? They go in the name sometimes, like python2. Names aren't consistent everywhere, either. The name of a package in all-packages.nix might need to be different from the name in its own derivation source. Good luck finding it.
Not every package gets a global name, either. Some are moved into separate attributes sets. Some get both.
https://news.ycombinator.com/item?id=38933136
| 17:45:42 |
9999years | ^^ i've long wished for a generated list of every 'public' nixpkgs attribute. it really sucks that there's no better way to find package names than reading the source or guessing and praying. the manual lists a few of the special cases like pythonPackages, but there's lots of stuff that's kinda weird and less documented than it should be (like is there a difference between python.pkgs and pythonPackages? no clue) | 17:48:42 |
K900 | search.nixos.org is that? | 17:49:39 |
K900 | Except a few attrsets that are explicitly included | 17:49:46 |
9999years | actually i just checked the manual and it does say that pythonPackages is an alias for python.pkgs (though it doesn't say how the python version for those sets is chosen/updated), but there's no way to get this information directly, especially in an editor -- you always have to switch to your browser and start searching | 17:49:48 |
9999years | In reply to @k900:0upti.me search.nixos.org is that? ooh, forgot about that (it wasn't around when i picked up nix). it would be great to have that interface available in a text editor! is it possible to run the nixos search (options or packages) locally yet? | 17:50:55 |
K900 | Yes? | 17:52:12 |
K900 | nix search nixpkgs foo | 17:52:15 |
9999years | not quite!
$ nix search nixpkgs haskellPackages
error: no results for the given search term(s)!
| 17:56:10 |
K900 | It doesn't match attrset names | 17:57:03 |
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 |