distrobox: add module

[aguirre-matteo]

Description

Added programs/distrobox.nix module. It provides the option "programs.distrobox.containers", which makes it possible to declare a list of containers to be created. Since building those containers is not possible at build time (because none container backend is available at that time), I also added the options "enableBashIntegration" and "enableZshIntegration", which adds some code to .bashrc and .zshrc respectively that looks for changes in the file "containers.ini" and prompts the user to build the containers.

Support for other shells, like Fish and Nushell, will be added soon.

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all
  or nix build --reference-lock-file flake.lock ./tests#test-all using Flakes.

• Test cases updated/added. See example.

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.

Maintainer CC

[aguirre-matteo]

Support for Fish and Nushell has been added. So the pull request is ready to be merged.

[khaneliman]

should be moved to linux only section

[LuNeder]

Cool!

Since building those containers is not possible at build time (because none container backend is available at that time), I also added the options "enableBashIntegration" and "enableZshIntegration", which adds some code to .bashrc and .zshrc respectively that looks for changes in the file "containers.ini" and prompts the user to build the containers.

Wouldn’t a systemd unit be a better option for that, working regardlessly of the users shell and with no need for interaction?

[aguirre-matteo]

@LuNeder It should be a better option, but how could I prompt the user for confirmation? Try to open a terminal periodically doesn't seem like the right solution to this problem.

By the way, is Bash always available in NixOS? I know about the symlink in /bin/sh. I think it should, given there's no programs.bash.enable option.

If that is true, it would be better to write the script just for Bash, and running "{pkgs.bash}/bin/bash /path/to/script.sh" in the rest of shells.

[LuNeder]

It should be a better option, but how could I prompt the user for confirmation? Try to open a terminal periodically doesn't seem like the right solution to this problem.

Why does it need user confirmation? If the user edited the config they probably want it to get applied, right?

By the way, is Bash always available in NixOS? I know about the symlink in /bin/sh. I think it should, given there's no programs.bash.enable option.

If that is true, it would be better to write the script just for Bash, and running "{pkgs.bash}/bin/bash /path/to/script.sh" in the rest of shells.

Unfortunately there doesn’t seem to be an easy way to uninstall bash, and NixOS uses it on a bunch of scripts anyway. Besides, if you do “${pkgs.bash}” then bash will be installed anyway in order to fulfill that ‘placeholder’ so it shouldn’t be a problem. Still, why’s interactivity necessary here if the user is already editing the config and running nixos-rebuild?

[aguirre-matteo]

@LuNeder I replaced the shell's extra init code with a Systemd Unit. Here's the code:

systemd.user.services.distrobox-home-manager = {
      Unit.Description = "Build the containers declared in ~/.config/distrobox/containers.ini";
      Install.WantedBy = [ "default.target" ];

      Service.ExecStart = "${pkgs.writeShellScript "distrobox-home-manager" ''
        PATH=/run/current-system/sw/bin:

        containers_file=${config.xdg.configHome}/distrobox/containers.ini
        prev_hash_file=${config.xdg.configHome}/distrobox/prev_hash
        new_hash=$(sha256sum $containers_file | cut -f 1 -d " ")

        if [[ -f prev_hash_file ]]; then
          prev_hash=$(cat $prev_hash_file)
        else 
          prev_hash=0
        fi

        if [[ ! prev_hash == new_hash ]]; then
          rm -rf /tmp/storage-run-1000/containers   # <--- These two are because in some cases Podman complains 
          rm -rf /tmp/storage-run-1000/libpod/tmp   # and says to the user that those directories should be deleted
          $HOME/.nix-profile/bin/distrobox-assemble create --file $containers_file
          echo $new_hash > $prev_hash_file
        fi
''}";

But it builds the containers even if the previous hash is equal to the new one. This should be implemented to prevent from rebuilding those containers that have replace = true; when switching the config or at boot time, even if no changes were made to the file.