I mentioned another alternative to adding flake-specific metadata to data structures that are transferred over the network, as part of the signed traces or otherwise, in a comment on that PR Eelco linked.

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.

[dead]

In practicing no because in the end it generally takes a human intelligence to fully understand the requirements of a particular program, sanity check everything, get the right dependency versions and fix build errors. For code library repositories like rust, importing is fairy automated since everything is neat, tidy, and regular. But end user applications are more often than not a pain in the ass

That would be possible. The main problem there is that nixpkgs, the package repository one would want to translate, uses a good chunk of specialized build infrastructure (parts in nix, some in rust/Perl/Python) that is designed for nix (the package manger).

Some other semi-specific parts, like stdenv bootstrapping, are also a bit more complex than just some nix build instructions.

It's not to hard to translate manually, but since the dependency tree is massive it doesn't seem feasible to do wholesale.

[dead]

Guix uses a fork of the nix daemon

Guix uses the sandboxing logic iirc

Yeah, I tried it briefly some time ago and it seems like a solution.

It's both, multiple derivations can produce the same (content-addressed) store object, and the derivations may not be reproducible and produce different (content-addressed) store objects each time.

The reality of executing arbitrary programs on non-deterministic computers is, unfortunately, N:M!

(Cue deterministic WASM derivations or something.)

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.

> 2. listing the contents of the store directory would not be allowed

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?

What actually happens if you remove read permissions on the /nix/store directory? Do things still work? I suppose I'll need to try!

How could one debug if we couldn't view contents of the store directory?

That name is only there for debugging purposes. It doesn't actually mean anything and you only ever need to look at it to debug some hoary failing build.

Comparing nix style (hash head, package tail), and spack style (package head hash tail), and speaking from my own limited experience, the need arises in different cases, which also depends on the ease of tooling,

sometimes I'm grepping in /nix/store and you have (as shown earlier) a list of derivation paths like this

$ ls /nix/store | grep nodejs-2 | head | sed 's/^/ /'

    0a9kkw6mh0f80jfq1nf9767hvg5gr71k-nodejs-22.18.0.drv
    0pmximcv91ilgxcf9n11mmxivcwrczaa-nodejs-22.14.0-source.drv
    0zzxnv3kap4r4c401micrsr3nrhf87pa-nodejs-20.18.1-fish-completions.drv
    2a7y7d38x8kwa8hdj6p93izvrcl9bfga-nodejs-22.11.0-source.drv
    2gcjb0dibjw8c1pp45593ykjqzq5sknm-nodejs-20.18.1-source.drv

You might ask why are you grepping? Because it's fast and familiar and I don't know the native tooling as easily (possibly a UX problem).

Then in spack (see https://spack.readthedocs.io/en/latest/package_fundamentals....) they have

$ spack find --paths

    ==> 74 installed packages.
    -- linux-debian7-x86_64 / gcc@4.4.7 --------------------------------
        ImageMagick@6.8.9-10  ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/ImageMagick@6.8.9-10-4df950dd
        adept-utils@1.0       ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/adept-utils@1.0-5adef8da
        atk@2.14.0            ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/atk@2.14.0-3d09ac09

$ spack find --format "{name}-{version}-{hash}"

    autoconf-2.69-icynozk7ti6h4ezzgonqe6jgw5f3ulx4
    automake-1.16.1-o5v3tc77kesgonxjbmeqlwfmb5qzj7zy
    bzip2-1.0.6-syohzw57v2jfag5du2x4bowziw3m5p67
    bzip2-1.0.8-zjny4jwfyvzbx6vii3uuekoxmtu6eyuj
    cmake-3.15.1-7cf6onn52gywnddbmgp7qkil4hdoxpcb

Tradeoffs wise I think they both made the right choice. Because for nix, the packages are almost always in /nix/store, so the path length including the hash is almost always the same.

For spack you can place your packages anywhere so the base directories can be highly variable, and so it's sensible to have the package names immediately after the package directory.

Or, I'm just trying to rationalize the choices each designer made post-hoc. But after using both I appreciate the design considerations that went in. In the end, humans are inefficient. When I make name / version / hash identifiers in my own applications I end up using one or the either design.

Yes but why pay that runtime cost for a problem the user can solve in human time using grep?