Provide a non-interactive interface to Litterbox

[thund-x]

Using flags and options is marginally faster than answering to each prompt on each invocation. This lets users to create scripts to automate certain actions. For destructive actions (e.g. SSH key deletion), a -y/--no-confirm flag can be provided to override the prompt. -f/--force can be reserved for those cases when there will be collateral damage from an action (e.g. #66).

For backwards compatibility we can default to interactive mode, unless at least one flag or option has been specified. Code-wise this can be achieved by using Option<T> instead of T.

[Gerharddc]

This sounds like a good idea indeed. We could also have a flag which just uses the default options when building a new container as this is probably what people use most of the time anyway.

[thund-x]

I guess --no-confirm can be used for that purpose. In a sense you don't confirm/"answer" the prompts, you only spam Enter :)

[Gerharddc]

I guess --no-confirm can be used for that purpose. In a sense you don't confirm/"answer" the prompts, you only spam Enter :)

That is an option yes. But something with "default" in the name might be slightly less surprising to users 😅

[thund-x]

Sure, but since flags already contain defaults values, this is like saying "specify --defaults to use the defaults" which sounds a little weird to me. Ideally there should be a global flag to enable or disable interactive mode, something like --no-interactive/-I and its theoretical counterpart --interactive/-i.

[Gerharddc]

Fair enough, default is indeed a bit confusing. Perhaps we can start by not forcing users to choose all the settings when they create a new litterbox (i.e. just ask them if they want to define any non-default settings at all first). We could then have --no-prompt or --no-interactive just assume they would have said no.

[thund-x]

Perhaps we can start by not forcing users to choose all the settings when they create a new litterbox (i.e. just ask them if they want to define any non-default settings at all first)

This implies users already know what the defaults are. Also, isn't already there a prompt for existing litterboxes asking users if they want to change settings in general? Asking later on if they wish to use the defaults or not feels repetitive.

We could then have --no-prompt or --no-interactive just assume they would have said no.

I prefer --no-prompt because it's shorter.

[Gerharddc]

This implies users already know what the defaults are. Also, isn't already there a prompt for existing litterboxes asking users if they want to change settings in general? Asking later on if they wish to use the defaults or not feels repetitive.

Currently you are only asked if you want to change settings when you rebuild a litterbox. On the original build you currently get asked about all the settings. I think this is useful, but it might get problematic at some point if there are too many options. So it is something to think about.

I prefer --no-prompt because it's shorter.

Sounds good yes.

[thund-x]

Currently you are only asked if you want to change settings when you rebuild a litterbox. On the original build you currently get asked about all the settings. I think this is useful, but it might get problematic at some point if there are too many options. So it is something to think about.

Okay fair enough. The user would still need a way to know the default settings prior to accepting them.

[Gerharddc]

The user would still need a way to know the default settings prior to accepting them.

Indeed. If someone chooses to just use defaults, we could inform them to go check the settings written to the .ron file, or do you think that is not enough? The default settings are also the most conservative from a security standpoint, so I also don't see a risk if someone uses them by accident.

[thund-x]

I believe a final message saying "Settings written to X" will suffice. Curious users can open that file.

[ovo-Tim]

Another thought is we should have --import, which allows the users to automate creation process. And defining what to mount(#69) in the config file is also nicer.

One more bolder thought is we could have --seamless, which provide you a distrobox like experience.