[allan-a]

> Instead of a flat directory tree with hashes, a consistent algorithm that categorises apps and puts them in a tree:

> /gonix/apps/gui/productivity/images/krita/5.1/

> /gonix/apps/console/shell/bash/5.2/

> /gonix/apps/programming/compilers/fpc/3.1/

> /gonix/libraries/c/glibc/2.39

> /gonix/apps/console/editors/vim/9.1

This is a nice illustrative example that works well when the only difference between software packages is semantic versions. The reality is that there can be many variants of packages and using something like a hash of package inputs is very practical. Take for example a library called GDAL, which has an insane amount of configure flags. It is quite common for scientific software to be tuned and package maintainers cannot supply a one-size-fits-all solution.

[lproven]

OK. For clarity, I am not anti-hash or anything.

For instance, we could still embed the hash in the directory name, in much the same way that many Linux programs use build numbers.

/gonix/apps/console/editors/vim/9.1~246dea34451dbdda21

The core things that I'm getting at here are:

1. Put the human-readable part first because humans see that first.

2. Retain hierarchical layouts. For humans this makes things more manageable and accessible, while for programs, as long as it's computationally-parseable the impact is negligible.

3. Lean in to the hierarchy. If it's necessary to duplicate slightly different versions of dependencies for different programs, then put them inside that program's hierarchy. That's one of its reasons for existing.

4. Embed the hash anywhere a simple regex can find it, no problem; tab-completion can sort that out.

All I am trying to suggest is that a Nix/Guix/successor/replacement type tool could focus more on ordinary joes who find it hard to remember the difference between `/bin` and `/usr/bin` as it is, and make stuff human-readable first and machine-readable second.

[trws]

@tgamblin beat me to it in a sibling here, but this is exactly why I like spack’s way, it mostly gives you the best of both. Now I need to go finish that PR to make it usable as an actual distro…

The only one that doesn’t quite work out is 3. Dependencies are vendored like that when it’s a patched version that can only ever be used with one package, but in general it helps more to have the regular structure to let them be shared. Otherwise we would have to move them when a new dependent appears and some other kinda funky things. I have played with having each package get a “view” of links to all its deps in its prefix, but it’s a high cost in inodes for an only moderate increase in observability. Pretty easy to generate your own (there’s literally a command for it) so not sure if it’s worth it.

[tgamblin]

FWIW this is what Spack does, and it uses a store layout like nix/guix. here are some chunks of the spack install tree path. All you really need is the hash, but we provide a bit more.

    $ spack find -p
    ...
    cmake@3.27.9             ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x6g5fl54kgt4nqmgnajrtfycivokap2p
    cmake@3.27.9             ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/cmake-3.27.9-x4bznyafesvpdbplqhmnwwvy2zj5fdzs
    coreutils@9.3            ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/coreutils-9.3-vlwyg7d3ysxfoom3erl6ai4yy7fuf2jn
    curl@8.4.0               ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/curl-8.4.0-zjz6twa32vxnevika34kkrxjwo27z6vj
    curl@8.6.0               ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/curl-8.6.0-da5tk7aqaqp6zdligjmahzwohzut65qc
    diffutils@3.9            ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/diffutils-3.9-lau4vo7zlsktmbhyn3pf3x72nxhihsaq
    double-conversion@3.3.0  ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/double-conversion-3.3.0-zihvj7vzedapjprk76awr7qied3k45n6
    emacs@29.2               ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/emacs-29.2-x5v4wdhp4vfsuxquadackqckdvxrppwi
    expat@2.5.0              ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/expat-2.5.0-hmdysf6hcrzuhcxu7fkecpvskzxecgps
    findutils@4.9.0          ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/findutils-4.9.0-atynmdjhdjpb2ipurlk7cxtdep77m7mu
    fish@3.6.1               ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/fish-3.6.1-sg3ws3rmbfgdfyhvjnhd5agepguj4yf2
    flex@2.6.3               ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/flex-2.6.3-quw6ammnjxfutqtqcifvjfsp5nyqpeab
    freetype@2.11.1          ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/freetype-2.11.1-ue2ofutkkawtzvcl47pqts4lasm5lgha
    gawk@5.2.2               ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gawk-5.2.2-jld7vb24rls64nbzkyxcp4alluyedfzv
    gdbm@1.23                ~/spack/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/gdbm-1.23-amtpuskagocirjhffgqrjas3bfbnzixi
    ...

You can also customize the install tree paths[1] with format strings; the default is:

    config:
      install_tree:
        root: $spack/opt/spack
        projections:
          all: "{architecture}/{compiler.name}-{compiler.version}/{name}-{version}-{hash}"

One reason `nix` uses `/nix/HASH` is because it results in shorter paths and avoids issues with long paths. We use sbang[2] to avoid the most common one -- that long shebangs don't work on some OS's (notably, most linux distros).

[1] https://spack.readthedocs.io/en/latest/config_yaml.html#conf...

[2] https://github.com/spack/sbang