In the future, Nix will hopefully gain proper provenance tracking that will tell you exactly where a store path came from: https://github.com/NixOS/nix/pull/11749
As Martin Schwaighofer has discussed, it is fine and in fact good for build traces entries to have arbitrary meta data, so the "claims" being cryptographically signed are more precise. (This is good for auditing, and if something looks suspicious, having full accountability.)
So on that grounds, if eelco would like to include some "this came from this flake" information as informal metadata. (formally the key must still the resolved derivation.) That is fine with me.
---
As I linked in my other reply, see my fast-growing https://github.com/NixOS/nix/pull/14408 docs PR where I try to formally nail all this stuff down for the first time.
It's keeping flake-specific data locally, to guarantee that it matches how the user ended up with the data, not how the builder produced it. I think otherwise from the user POV such data could again look misleading.
A different type of madness, but are ugly names so common, why not start with ruby-3.3.9 so any list of files is semantically sorted/readable?
The semantic is "what did this configuration generate", not "what's this package's version".
> 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?
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.
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 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".
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
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.
rkomorn.skills.tty.tab_completion -= 1;
1. store paths would have no names at all
2. listing the contents of the store directory would not be allowed
3. store paths have more bits of information
Then store paths are halfway decent (but non-revocable) capabilities.
You can still use root or something to list all the store paths. (But ideally nothing else would be running as root / with that power.)
Wow, that's awful, that's what Windows AppStore does, so it's even hard to see how much of the preinstalled garbage there is or even whether you might have a huge game you forgot to uninstall but might want to to free up some space.
What's the cool benefit that could justify this limitation?
Also. Check out Farid's other posts.
Nix was a great research project. Now is the time to rewrite it from the ground up.
- a more "academic" spec of what it does
- nuts-and-bolts JSON schema for many data types
- JSON golden tests instead of C++ literals in the unit tests as often as possible.
I hope this will make additional store layer easy to churn out.
(The "hash derivation modulo" that is so fiddly described in this blog post can be dropped in a world where we no longer have input addressing, and just have content-addressing. Or, in a world where we have a new, simpler type of input-addressing instead.)
beardsciences•6h ago
setheron•5h ago
The point of the article to me (author) was that i found it odd that Nix replaces the derivations when calculating the output path but not the derivation path. (talking about "paths" in Nix is so hard!)
beardsciences•5h ago
Ericson2314•5h ago
I've recently started some fancy formal spec-level documentation here https://github.com/NixOS/nix/pull/14408 The "resolution" equivalence class is both simpler and better than the "hash derivation modulo ..." one.
(The fact that it is a mouthful to say what the derivations are modulo kinda gives the game away! I put "hash quotient derivation" in the docs to side-step the issue.)
edolstra•5h ago
CA derivations also introduce the opposite situation, namely that the same derivation can produce different output paths for different users (if the build is not bitwise reproducible).
setheron•5h ago
Ericson2314•3h ago
The reality of executing arbitrary programs on non-deterministic computers is, unfortunately, N:M!
(Cue deterministic WASM derivations or something.)