Option to run system-wide Nix on systems with Nix installed

[Thesola10]

This would allow for nix-portable to be used in much the same way as gradlew and be shipped with projects. On systems with Nix, nix-portable would be able to detect and run the system-wide install of Nix instead of itself. This behaviour could be modified with a flag or environment variable.

Alternatively, nix-portable could obtain access to the system-wide Nix store or talk to the system-wide Nix daemon if it detects it, so that the sandbox is retained, but the risk of data duplication is reduced

[DavHau]

Sure sounds good. Feel invited to open a PR

[Thesola10]

Never mind that, while attempting to bump the nixpkgs version I found out that static Nix binaries can now use a chroot out of the box since 2.10

I'm looking into building a Nix user experience à la gradlew with a much simpler design leveraging this new feature

[Thesola10]

Nixie is the result of this line of thinking, and is very close to native macOS support too!

[DavHau]

Interesting to see an alternative solution emerging. I'd be happy to deprecate nix-portable in favor of a better solution.

Things that I like about the nixie approach which are missing from nix-portable:

• integrating nix with the repo itself
• downloading the best version of nix dynamically instead of embedding it inside our own executable statically
• falling back to an existing nix if installed
• macos support

Drawbacks that I currently see with nixie's approach:

• The chroot feature of nix is not well tested. As reported in nix-static: problems on common distros NixOS/nix#7908 I ran nix-static against the test pipeline of nix-portable and commands like nix-shell are currently broken on all distros except nixos.
• The chroot feature of nix relies on user namespaces which is not enabled by default on some distros. As you can see in the test suite of nix-portable I had to disable bwrap for centos7 and debain because of this. Instead nix-portable is falling back to using proot on these distros, something which is not supported by nixie.
• Nixie is not tested continuously against common distros or environments like nix-portable is.

What are your thoughts regarding these drawbacks?

I have the following ideas how we could move the whole story forward:

• Upstream the test-pipeline of nix-portable to nix itself to ensure that nix-static becomes reliable.
• Think about how we can integrate proot or proot-rs with nix-static or nixie. (Or maybe build something like fakedir for linux, as a more minimal alternative for proot).

Some additional ideas:
I think for some environments, especially like docker containers, the best option would be to just create /nix instead of using a fragile sandboxing solution like proot. Maybe that could be a valid approach for macos as well. If /nix doesn't exist, try creating it via sudo or instruct the user on how to create it.

[Thesola10]

You raise some very good points, so let me address some of the drawbacks:

• I've read through the bug reports abot failing chroot, and it all seems to link back to a couple issues:
  • The lack of a <nixpkgs> channel. The intended workaround is the ability (and automated default) to embed Nixpkgs into the script's resource tarball.
  • The lack of a git executable. The Nixie script itself requires git, and being run in a Git repository, so any usage where git is missing is unsupported.
• An increasing number of distributions are now supporting unprivileged user namespaces, as that is a hard requirement for Flatpak. If your distro supports Flatpak, it supports this. Of course, having a workaround is a good idea, I'll look into including proot.
• That third point about continuous testing is absolutely a great idea, I'll be working on it when I'm done with the base feature set. That, and upstreaming as much of the test process to the official Nix static project of course.

As for the Docker thing, I've made sure that the script works out-of-the-box in the nixos/nix image, and I assume users usually have a say on which image to use in most Docker environments. I might add a flag for rootful Nix setup, or falling back to the official Nix installer.