Looks good. I think there was the idea that upstream repo names sometimes change (which causes a rebuild if the repo name is included into the source derivation name). Should we check how often this happens in practice in Nixpkgs?

Looks good. I think there was the idea that upstream repo names sometimes change (which causes a rebuild if the repo name is included into the source derivation name). Should we check how often this happens in practice in Nixpkgs?

For me it looks like a no-brainer, but there is indeed a small risk. This risk is mostly alleviated by the hydra cache, so that the name will only really need to change when version changes, and in that case you should exêct changes in the sources themselves.

No, we explicitly moved to source to prevent variation between various fetchers and spurious rebuilds. See c3255fe and NixOS/nix@65b5f17.

A concrete example of why we don't want to include the repo name: it would cause different store paths for the same commits from the nixpkgs and nixpkgs-channels repositories.

It makes sense in the current state of Nix. This is the kind of workaround/limitation that a CAS implementation would fix.
Thanks for explaining further BTW.

Can you point out how it would be fixed? These basically are content-addressable already, and we keep the names the same so that the addresses are the same more often.

In this case, there is a confusion on whether the name should be part of the content. In a real CAS, it clearly should not. In this case, for good reasons, we are trying to mimic a CAS for these source paths, but we deprive ourselves from some ways to know where it comes from, that we would have in CASes as I see them.

Speaking of which, we could further narrow the gap from a real CAS by having /nix/store/<hash>-nix-2.0.1-source.drv producing /nix/store/<hash2>-source but I am not aware of any way to decouple the .drv name from the output path name.

BTW, "cas" may be a better name than "source", as it hints at the reason why we `constantify' it.

Well, I meant it confused me that in the first post you desire more human-meaningful information in the name and in the last it seems the other way around. I suppose you assume we'd have some kind of meta-data passed along (while excluded from content) that would contain extra information like human-meaningful name? (And/or information about one or more of its possible *.drv.)

Well, I meant it confused me that in the first post you desire more human-meaningful information in the name and in the last it seems the other way around. I suppose you assume we'd have some kind of meta-data passed along (while excluded from content) that would contain extra information like human-meaningful name? (And/or information about one or more of its possible *.drv.)

That's it !