A user-friendly wrapper around nix would be much more functional (in all meanings of the word) and interesting than any of those solutions. Unfortunately, the world is moving in the opposite direction.
The rest of the world is adopting docker, flatpak, snap, appimage, etc which all just ship a whole os along with the app.
Nix is reinventing one aspect of SCO Unix but better, and flatpak/appimage/snap are reinventing static binaries but grossly worse.
Not something anyone dreamed of I guess.
https://nix.dev/tutorials/nixos/building-and-running-docker-...
With a Flake, you just need to declare a new output like this: https://github.com/aksiksi/ncdmv/blob/ebd57d02a0fe653e277003...
Then to build it:
nix build .#docker && docker load < ./resultSco didn't have anything like the nix dsl and config files that really makes nix what it is, nor containers to provide virtual environments, just that all the os files were really just symlinks.
But now I would say, separately, that Nix probably is better than all-apps-are-containers, but anything is better than that so it's not remarkable and not what I meant.
One way nix's package configs are better than container packages is that even though each app gets to declare it's own custom versions or builds of all of it's requirements which might differ from their neighbors resulting in multiple copies:
1: anything an app doesn't declare is still shared.
2: even declared special versions are shared. The app only contains a config file that says it needs libfoo 1.2, or libbar built with non-default option Y enabled etc, not a copy of the library.
The os only needs to contain one copy of each unique version of something, not one copy per installed package.
It's better in several ways and the space consumption is probably the least important.
For one thing it puts the ultimate power of configuration back in the end user and distro maintaners hands instead of every random package developer putting whatever haphazard crap they want into your system just as lazy support for their app. Instead of getting a container with it's own sshd inside, you get a config file that someone better wrote that describes how to satisfy the apps needs in some acceptable way, not necessarily the same exact way the app developer did in their docker or flatpak.
The config also serves to expose everything which makes it easier to find and improve things.
A container that just includes the world and all it's 700 little unknown forgotten hacks is hard to audit and replicate. It's the laziest of lazy shitty solutions. It's just copying the developers laptop instead of figuring out and documenting how to produce something. "I have no idea how I got here, so here's just a copy of everything as it currently is."
But the equivalent config is like a diff that shows every single detail, and gives the os maintainer, the package maintainer, and the end user the chance to see, accept, or alter all of those details.
And I'm not actually a fan of Nix. It's just that package containers are such a lazy shitty gross solution that all other solutions are better.
In particular, what I find so misleading about saying its "moving in the opposite direction" is that it makes it sound like the success of Docker and whatnot is coming at the expense of approaches like Nix which I just don't think is true.
Almost nobody thinks docker-style containerization is the perfect solution to reproducibility, rather its a usable stopgap solution to just get something working without requiring the user to change their OS. In fact, I think a lot of the interest in, and adoption of Docker is making more and more people aware of the downsides and hitches with containerization, and is driving at least a subset of users towards Nix-style approaches. I think in the long run, this will benefit Nix.