Choose a profile when cloning a box - #240
Open
kacperpaczos wants to merge 2 commits into
Open
Conversation
Creating a box already accepts a custom home directory, but it is a bare path field: nothing says what it changes, and anyone using it for more than one box has to remember the paths and retype them. A profile is that directory with a name on it. The primary menu gains a Profiles window listing them, each with the directory it points at, a Browse button that opens it in the file manager, and Remove. Adding one takes a name and puts the directory under ~/boxes; the directory itself is created when it is first needed rather than up front, since distrobox makes it when a box is built and Browse makes it when someone looks. The new-box form gets a Profile combo listing "Host (shared home)" first, then the profiles. Picking one fills in the home path; picking Host clears it, which is distrobox's own default and what every existing box uses. The folder picker still works for a one-off path, and the value handed to distrobox is unchanged - so this is a way of choosing the existing option, not a new mechanism. Profiles live in GSettings as a name-to-path map, the way exported-app labels do. Removing one forgets the setting only: the directory and any box already built on it are left alone.
A container's home directory is fixed when it is created, so an existing box cannot be moved onto a profile. Cloning is the way round it, and it is the safe one: the copy is built with the new home and the original is left exactly as it was, so nothing is lost if the copy turns out wrong. The clone dialog gains the same Profile combo the new-box form has, and a line saying what it does. `clone_box` takes the chosen home and passes it to distrobox as `--home`; with "Host (shared home)" the arguments are byte-for-byte what they were before, which a test pins. Building those arguments is factored into `build_clone_args` so the shape can be tested without running distrobox.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #239, and the answer to the question that PR left open: how an existing box gets onto a profile.
It cannot be moved onto one. A container's home directory is fixed when it is created - podman does not change a running container's mounts, and distrobox has no command for it. Recreating the box would mean losing everything installed in it.
Cloning is the way round it, and it is the safe shape: the copy is built with the new home, the original is untouched, and nothing is lost if the copy turns out wrong. BoxBuddy already clones; this only adds the choice of where the copy's home should be.
clone_boxtakes the chosen home and passes it to distrobox as--home.distrobox create --clone X --name Y --home Zis valid:--homesetscontainer_user_home, which is used when the new container is created regardless of the image coming from a clone (distrobox-createlines 726 and 892).clone_boxalready stops the source first, which distrobox requires for a clone.Testing
cargo test: 10 pass. Three are new, onbuild_clone_args, which was factored out so the argument shape can be checked without running distrobox: with no profile the result is exactly["create", "--clone", src, "--name", new]; with one it ends with the--homepair; and source and destination land in the right positions.End to end on a virtual display, with a stub
distroboxlogging what it was called with:So the existing behaviour is unchanged unless a profile is picked - which is the point.
One implementation note: the chosen path is read without consuming it, so a click that comes to nothing (an empty name, a clone that fails) leaves the choice in place for the next attempt.