Permit autoproj to perform configuration noninteractively by relying …

[2maz]

…on the default values

Avoid the need for updating seed configurations when new configurations options are introduced to autoproj.

[planthaber]

+1

Good change, makes maintaining CI way easier.

[g-arjones]

In principle, I like the idea... I wonder if we should maybe skip saving the configuration if AUTOPROJ_NONINTERACTIVE is enabled and also maybe add a --no-interactive option in the CLI.

What do you guys think?

[2maz]

skip saving the configuration if AUTOPROJ_NONINTERACTIVE is enabled

what would be the use case, seed-configurations might still be used in combination with a non interactive mode

maybe add a --no-interactive option in the CLI.

+1 but maintaining the control through the env var

[g-arjones]

what would be the use case

Automation tools and/or the vscode rock/autoproj extension during operations other than install/bootstrap. Also, this could be a fix/workaround for #200 but we would still want the user to be asked about the configuration in the future

but maintaining the control through the env var

Sounds good..

[planthaber]

What do you think about to also set --no-color and --no-progress when AUTOPROJ_NONINTERACTIVE is set?

[2maz]

Automation tools and/or the vscode rock/autoproj extension during operations other than install/bootstrap. Also, this could be a fix/workaround for #200 but we would still want the user to be asked about the configuration in the future

Sorry, still not clear to me as to why you do not want to save the configuration.
From my (most likely limited) point of view, not to save the config means: you always want to stick to the defaults?
However, with non-interactive mode (for CI, unattended deployments ..) a user might still provide a seed-configuration to be used for the bootstrap.
This configuration should be applied and it should stick - independently of the changes to the defaults might be made.

[doudou]

This configuration should be applied and it should stick - independently of the changes to the defaults might be made.

This actually sounds weird. If non-interactive picks up defaults, then why don't you want to use the up-to-date defaults, in case they change ? Especially in CI, it would make sure that the default build actually builds...

I actually like @g-arjones idea of not saving the values (if it's reasonably easy to do), allowing to bootstrap non-interactively and then do a manual run to check the configuration(s). This seems compatible with having a seed file (which only consists of reading values, not writing them).

Finally, I would very much prefer that the flag is made available on the configuration object (Configuration#interactive?). I'd be fine to have it only through the envvar for now, but in the future, I'd also prefer being allowed to pass it explicitly on the command line and/or through the seed file (e.g. during bootstrap, the way --separate-prefixes works). Putting it on the configuration object would allow for this. Given that BuildOption is stored on a configuration object in the first place, this seems reasonably easy to do (have #interactive? on the object, and pass it as argument to #ask instead of implicitly through the env var).

Also, please write tests.

[doudou]

What do you think about to also set --no-color and --no-progress when AUTOPROJ_NONINTERACTIVE is set?

👎 You can run noninteractively in a terminal emulator that supports color and/or progress.

[2maz]

This actually sounds weird. If non-interactive picks up defaults, then why don't you want to use the up-to-date defaults, in case they change ? Especially in CI, it would make sure that the default build actually builds...

Well I did not say that. To be clear I am stressing the fact that the configuration options which a user sets explicitly via the seed-configuration should be maintained.
These should not change just because the default of an option has changed.
That is why have been asking for clarification on the issue of not saving "the configuration".
if @g-arjones is suggesting (and @doudou s response now implies this) to skip saving only those configuration options that are set through a fallback to default - then I am fully with you.

then do a manual run to check the configuration(s).

What is that supposed to mean?

Finally, I would very much prefer that the flag is made available on the configuration object (Configuration#interactive?). I'd be fine to have it only through the envvar for now, but in the future, I'd also prefer being allowed to pass it explicitly on the command line and/or through the seed file (e.g. during bootstrap, the way --separate-prefixes works). Putting it on the configuration object would allow for this. Given that BuildOption is stored on a configuration object in the first place, this seems reasonably easy to do (have #interactive? on the object, and pass it as argument to #ask instead of implicitly through the env var).

Sure, I can put something along these lines together

[g-arjones]

Exactly what I meant, sorry for not being clear enough. I guess we are all on the same page then..

[doudou]

What is that supposed to mean?

Well ... start a non-interactive bootstrap/update/build and go to lunch. When you come back, run amake interactively, this time, and check the flags. You only need to rebuild stuff you would have changed.

[2maz]

Update: Implemented something that hopefully covers all mentioned requirements. I need some help for the test side, however, see comment above.

[g-arjones]

I don't see how you are skipping saving options that had defaults chosen due to non-interactive mode...

[2maz]

I don't see how you are skipping saving options that had defaults chosen due to non-interactive mode...

sorry, apparently missed that one ..

[2maz]

I don't see how you are skipping saving options that had defaults chosen due to non-interactive mode...

Added the feature ...

[g-arjones]

Other than a few style issues (@doudou will probably have something to say about those) I think we are good to go

[doudou]

Hey ... thanks for taking care of this. Just a few comments on my side.

[doudou]

Thanks for the work Thomas !

[2maz]

got a bit meatier than I thought initially, but happy to had your reviews @doudou @g-arjones

[g-arjones]

@2maz 👍

any time!