[Discussion] Modularize distrobox

[tomeichlersmith]

As discussed in #511 , the best way to make integrating other runtimes easier and better is to "modularize" distrobox. This would involve pulling out common code into functions and making the scripts that are actually called by users only focused on parsing the CLI.

@89luca89 started working on this in #430 but this branch has gone stale and lost many improvements that have been put onto main. I tried a simple rebase and a simple merge and neither was easy. I think the best solution is to re-branch off main and re-do this modularization.

My goal of using the apptainer/singularity runtime informs the proposed design. From #430 , it looks like the actual unique commands are create, enter, list, and rm. (I am adding list and rm since I know that the apptainer/singularity interface will need a different implementation than the docker/podman).

Design Structure

- distrobox : entrypoint command
- lib/
  - deduce_manager : deduce what container manager (and what group) to use from env variables and/or autodetect
  - <other "higher level" commands like ephemeral and upgrade>
  - docker/
    - create
    - enter
    - rm
    - list

with this setup, then distrobox can have the function definition doing a specific task change depending on the container manger.

. "$(dirname "${0}")"/../lib/"${deduced_container_manager_group}"/<task>

could define the necessary function to run that would be given the arguments deduced by the CLI or, perhaps even easier, the file at $PREFIX/lib/<manager>/<task> is a POSIX script itself.

Currently, since podman has the same CLI as docker, they would both belong to the same "group". Grouping managers into similar (or even identical) CLIs allows us to save on code duplication. Similarly apptainer and singularity would share a group.

Each container manager group would be required to perform the create, enter, rm, and list tasks. Other tasks that require docker inspect (like automatic removal of the container's home directory) would not be implemented for other container groups, but this structure allows for more "fundamental" tasks to be defined in order to unify the CLI across different managers.

---

@89luca89 I plan to start work on this and I am hoping for your feedback. I think this could supersede #430 but also I plan to copy over the work you did with starting to write tests and updating the install script to handle the lib directory install as well. Moreover, I'm curious about the other PRs currently open - should any of them be merged before these developments? (i.e. to try to avoid the stale-ness that happened last time).