Nix Derivation Madness

it's primary for every human involved, also, the way you check whether it's changed is by automatically comparing that full hash, not its starting symbols, so you don't care where in the full string it's positioned

> The semantic is "what did this configuration generate", not "what's this package's version".

Then why have the name/version at all like in those nameless cache dirs?

It made sense to me when I looked at it, at mount points, at when it changed vs when it didn't, etc, so IDK what to tell you.

FWIW, I'm also pretty sure I'm human.

Edit: also, I'm pretty sure that I wouldn't find it any more or less complicated if the package name came first.

> at when it changed vs when it didn't

You still have this information! Just in a way where it becomes easier to track the difference or see how many rubies you have etc

> FWIW, I'm also pretty sure I'm human.

So you do read the "ruby" name/version , not just the hash?

I don't care how many rubies I have, except for disk space, which I clean up regularly, so it's a bit moot.

I actually don't look at the package names either as much as I look at the number of hashes, which I find easy to eyeball.

Quite frankly, I don't really look at the paths anyway (on any kind of regular basis). I just know that when I've looked at them, the hash vs package name thing made sense to me because of the configuration -> result relationship. :)

Edit: oh, when I said I'm pretty sure I'm human, I meant "I'm human too but I don't seem to be seeing things the same way you do".

> Edit: also, I'm pretty sure that I wouldn't find it any more or less complicated if the package name came first.

rkomorn.skills.tty.tab_completion -= 1;

> I don't care how many rubies I have, except for disk space, which I clean up regularly, so it's a bit moot.

So you do care about how many rubies you have (one of the nix issues is indeed its size), especially if it's not a ruby but some bigger dependency. Your solution is doing regular cleanup, another option would be to casually notice while browsing in a file manager or even clicking the "size" column, in which case reading left to right from the name would help noticing the dupes and maybe doing something about it.

> Quite frankly, I don't really look at the paths anyway

So you were just arguing for the fun of it based on a superficial theory?

> I'm human too but I don't seem to be seeing things the same way you do

Yeah you do, you read left to right and there is no way you read "sadlfkjasdlfwroiupdfoser" as well as you read "ruby-1.2.3". Though since you don't actually read that you don't care about it, that's also human, though not the level of human that matters for this argument

Yeah, okay. Super cool HN comment quality.

> So you do care about how many rubies you have

No, I care about how many leftover rebuilds I have that I no longer use (typically all of them). Couldn't care less about any individual packages because I leave it to Nix to know what should be installed and what shouldn't.

I don't casually browse through the stores because I have no reason to.

> So you were just arguing for the fun of it based on a superficial theory?

Arguing? That's not what I'm doing, but maybe it's how you feel. Your initial post was a question. I replied to it. I guess your question was rhetorical, based on your responses to my comments.

I was giving you my perspective.

My various dealings with the paths comes from various adventures of debugging why my configs didn't produce what I thought (eg things not in path). It's also probably why I see the relationship as starting with config and ending with path on disk.

I have never gone on fishing expeditions around store paths. When I go out of my homedir and "root" fs, I know what hash I want from looking at a symlink, or some log output.