[Suggestion] Hooks that run only during the creation of the container

[YoRyan]

Is your feature request related to a problem? Please describe. Currently, there are three ways to modify a container image with distrobox: the additional_packages list, the init_hooks script, and the pre_init_hooks script. Each method fires when distrobox-init runs, which is to say, every single time a container is started, including when entering it after a period of inactivity with distrobox-enter. These hooks can potentially burn a lot of time and would seem to go against distrobox's philosophy of making distrobox-enter as performant as possible. The official distrobox-assemble documentation includes examples that install Go, Deno, and Bun using the init hook, and these operations, again, fire during every container start.

Describe the solution you'd like Perhaps there should be a create_hooks script that would run only when creating a container with distrobox-create. And distrobox should consider moving the "Installing basic packages" step out of distrobox-init and into this hook. Once a container has been created, I can't think of a good reason why the package list should be installed again. If any are missing, it would be because the user explicitly uninstalled them.

Describe alternatives you've considered You could build custom images for distrobox using a Dockerfile, but that's a lot of ceremony for the kinds of customizations we apply to our distrobox containers. Hence why we have the additional packages list and the hooks in the first place.

You could clone an existing container to drop the defined hooks, while retaining your customizations, but that's not a very intuitive solution. It's only documented in a GitHub discussion.

Additional context

[wayneyaoo]

Second this. I actually thought it already acts this way, until today I cannot enter a distrobox created a few months ago because the initial hooks failed at a step (apt install stuff, like the OP mentioned) that I thought would only be executed at the creation time. It'd be great if we can have this feature :) so that we have less surprise, and when my box breaks next time I'll just use my assemble script to recreate one. Thank you!

[capfredf]

Third this. Currently I just work around this issue by creating a custom image using OBS. To be fair, it works fine with a small amount of drawbacks such as limitations of OBS and the gradually increasing size of an image that increases time to pulling the image.

I would really appreciate a hook for distrobox create

[goto-loop]

Absolutely agree with this. Just like @wayneyaoo, I assumed init_hooks were executed only at creation time until I couldn't enter an existing distrobox because one of the hooks failed.

[einarpersson]

I also assumed it was also only for when it was created. Sorry for spamming but I suppose these comments are a strong signal that the current behaviour is ununtiuitive.

[m-rz]

I also assumed it was also only for when it was created. Sorry for spamming but I suppose these comments are a strong signal that the current behaviour is ununtiuitive.

I fully agree, this was also the case for me. I realized when another issue (#1480) popped up and I needed to investigate. Ideally, there should be both init and startup hooks (or whatever we name them, but it needs to be documented well).

[matthewsanders]

I agree it would be good to have this functionality and would also agree that almost everyone probably assumes this is how they already work until they realize it isn't.

Another option that would be nice...

If the init_hooks had a clean way to reference the default user ( $USER is not bound apparently ) you could run an idempotent Ansible playbook ( or similar ) instead. This is actually a nice way to automate provisioning for development setups and keep your container updated.

I'm actually considering the second option now... but not sure how to access the user reliably from a distrobox.ini init_hooks for use with distrobox assemble.

It would be nice if the init_hooks could run as the default user with sudo capability as an option.

I didn't see many examples of non-root init_hooks apart from a suggested solution in this thread: https://github.com/89luca89/distrobox/issues/1407

However, that appears to imply a hard coded username be used when switching user.

I was considering using something like: init_hooks=sudo -u \$(id -u -n 1000) ansible-playbook \$HOME/ansible/playbook.yml --connection=local -i localhost,;

EDIT: I can confirm that does indeed work for my use case.

[pedrohqb]

I am in favour of such addition. However, until then, there is a workaround that I used in my assemble file: https://github.com/pedrohqb/distrobox-adv-br/blob/main/distrobox-adv-br

[spiteful-fox]

I agree it would be good to have this functionality and would also agree that almost everyone probably assumes this is how they already work until they realize it isn't.

Another option that would be nice...

I also thought that was how it worked. So... I decided to just make the option myself. Don't know for sure if it's "correct", but it's letting me do what I wanted to do with my assemble files. Maybe something similar to this? (https://gist.github.com/spiteful-fox/85bfca6983f0deee31a62b2f2632c350)

[findurance]

Indeed, it was a bit surprising to find out that init_hooks are executed at the creation and enter phase of the container.

Some things need custom scripts once at the creation only, so proposed improvements sounds good to me.

(On another note: it's unfortunate that if you have an error in the init_hooks, your created container cannot be entered into.)