It's my understanding that the ${hash}-${name} order is actually intended to help with tab completion, but from a different direction; if you already know the first couple chars of the hash, you can quickly tab-complete it, instead of using the less-unique name. I mean, I don't think that's the order I would have picked either, but there is logic behind it.
If you have an actively used Nix system with a large disk, it's very likely that you have a large number of (unused) deriations with the same prefix in there. A derivation is also a lower-level thing than a package, so it's not guaranteed that you have a useful name & version in there.
I just checked on my laptop and I have, for example, over 400 stdenv-linux build outputs in there.
To determine how useful something is it's important to look at the usecase.
My usecase for interacting directly with the store is that I want to look at some specific store path, so I already know the hash from somewhere and can autocomplete on the first characters with much higher precision than first completing drv names, and then moving on to the right hash.
You seem to have some other kind of use-case. What is it?
Comments
It's my understanding that the ${hash}-${name} order is actually intended to help with tab completion, but from a different direction; if you already know the first couple chars of the hash, you can quickly tab-complete it, instead of using the less-unique name. I mean, I don't think that's the order I would have picked either, but there is logic behind it.
Why would you remember anything from a hash instead of the infinitely more usable name+ version (a more-than-enough-unique combo?
If you have an actively used Nix system with a large disk, it's very likely that you have a large number of (unused) deriations with the same prefix in there. A derivation is also a lower-level thing than a package, so it's not guaranteed that you have a useful name & version in there.
I just checked on my laptop and I have, for example, over 400 stdenv-linux build outputs in there.
That still doesn't explain how 400 hashes are more useful than name+version+hashes
(this'd still suffer from the common fail of flat folders, should've used proper nesting, but not as much as hash-first)
To determine how useful something is it's important to look at the usecase.
My usecase for interacting directly with the store is that I want to look at some specific store path, so I already know the hash from somewhere and can autocomplete on the first characters with much higher precision than first completing drv names, and then moving on to the right hash.
You seem to have some other kind of use-case. What is it?
the usecase is described right there in the first comment
And 2_of_name + 2_of_hash is giving you higher precision in one match as it has more info to match against the full path vs just 2_of_hash