You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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!
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
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, theinit_hooks
script, and thepre_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
The text was updated successfully, but these errors were encountered: