Conversation
|
As we are slowly going to get rid of channels as a mean of distribution, it would be good to go towards something like https://github.com/bennofs/nix-index Meanwhile command-not-found in rust will do :) |
|
Agreed. I am just not sure how |
|
A couple of ways I can think of: a) encourage users to display it: b) hook into user profiile generation and run it then, like we do for some things that already depend on whole profile |
|
If moving towards a |
|
Just for statistics:
|
|
It's kind of awkward because nix-index relies on a completed Hydra jobset. We could probably set up a meta one just for nix-index though. Alternatively, we could go into the channel like programs.sqlite does (https://github.com/NixOS/nixos-channel-scripts/blob/master/generate-programs-index.cc). Unfortunately the db is pretty big (~30M) so I'm not sure if that's reasonable. See #39789 |
|
I wonder if it is actually worth having a database or if it would not be more efficient to just have a compressed text file that is search through linear. |
|
I'm up for switching to nix-index and all that, but you should note that (I'm using it for a while now) it's database lookup seems slower then the current implementation, I suspect it's due to the size of the database as it has paths for every file there is. Maybe we could modify nix-index a bit so it'll be able to generate a database of |
|
Maybe nix-index could accept multiple sources. Than we could ship one for |
|
I opened an issue for nix-index. Please focus on code review of this rewrite only. Replacing it with nix-index is beyond the scope. |
There was a problem hiding this comment.
Here's a review for the Rust code :)
I don't read perl, so I didn't compare the two implementations, but it looks like the Rust code is doing the right thing 👍
Most remarks are stylistic changes, with the exception of the inline use of exit, where I'm not sure if it's actually bad :)
7ebd296 to
9f153b3
Compare
|
Anything else? |
|
We should probably just get rid of |
|
When Flakes reach stable, yes, it should be removed but until then it remains as useful as ever and a clean rewrite is appreciated. Though even if they came in 20.09 this tool would be useful for at least another 4-5 months because I don't think we'll get Flakes in 20.03. |
|
I would suggest when nix gets flakes to disable the command-not-found module and just use |
9f153b3 to
56aeca2
Compare
puzzlewolf
left a comment
There was a problem hiding this comment.
LGTM 👍
What do you think about backporting this in 20.03?
|
@puzzlewolf That kind of change definitely shouldn't be backported to a stable branch. |
|
Agreed. This should be not part of 20.03. |
|
@edolstra Well, if you put it like that :D Sorry, don't know what i was thinking. |
jtojnar
left a comment
There was a problem hiding this comment.
It also seems to remove NIX_AUTO_INSTALL and NIX_AUTO_RUN support, which I do not see mentioned.
|
@edolstra asked me to remove |
56aeca2 to
54dddbd
Compare
Well, that's basically what nix-index does. It just does some simple text processing before that to improve compression rates and search speed (the same thing that locate db does: sort and encode common prefixes using a simple "repeat N chars of last prefix" approach) |
54dddbd to
ef51e5c
Compare
- drops perl + libraries dependencies Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
ef51e5c to
edaece2
Compare
Basically it is just that the full database is a bit too large. |
|
All issues resolved from point of view. |
|
I just switched to |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
see: NixOS/nixpkgs#88517 (comment) use `nix-locate` instead
Rust version of #74789 as @edolstra prefers Rust over C++: #74789 (comment)
Motivation for this change
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)