vng: override kconfig with '--force'

[matttbe]

By default, vng --build and --kconfig will not modify existing kconfig, even if new kconfig files are given. The idea is to let people modifying them manually.

It is now possible to force the modification of the kconfig by using '--force'.

Suggested-by: @arighi

[matttbe]

Should we also force the update when --kconfig is used?

diff --git a/virtme_ng/run.py b/virtme_ng/run.py
index c6b0468..a9fd566 100644
--- a/virtme_ng/run.py
+++ b/virtme_ng/run.py
@@ -157,7 +157,7 @@ def make_parser():
         "--kconfig",
         "-k",
         action="store_true",
-        help="Only generate the kernel .config without building/running anything",
+        help="Only override the kernel .config without building/running anything",
     )
 
     parser.add_argument(
@@ -562,11 +562,11 @@ class KernelSource:
                 dry_run=args.dry_run,
             )
 
-    def config(self, args):
+    def config(self, args, force):
         """Perform a make config operation on a kernel source directory."""
         arch = args.arch
         cmd = "virtme-configkernel --defconfig"
-        if not args.force:
+        if not args.force and not force:
             cmd += " --no-update"
         if arch is not None:
             if arch not in ARCH_MAPPING:
@@ -1102,9 +1102,9 @@ def checkout(kern_source, args):
 
 
 @spinner_decorator(message="🔧 configuring kernel")
-def config(kern_source, args):
+def config(kern_source, args, force):
     """Configure the kernel."""
-    kern_source.config(args)
+    kern_source.config(args, force)
     return True
 
 
@@ -1155,7 +1155,7 @@ def do_it() -> int:
         elif args.build or args.kconfig:
             if args.commit:
                 checkout(kern_source, args)
-            config(kern_source, args)
+            config(kern_source, args, args.kconfig)
             if args.kconfig:
                 return 0
             make(kern_source, args)

I don't know when vng -k is being used, but it would help if the idea is to do:

vng --kconfig --config CONFIG (...)
<change the config>
vng --build

[arighi]

Should we also force the update when --kconfig is used?

Hm... I'm not really convinced about this. I feel like we're going to break some workflows. At this point I'd rather prefer to introduce a new --update-config option, that seems also more intuitive than using --kconfig to update the config.

In this way your example becomes more clear I think:

vng --update-config --config CONFIG ...
<change the config>
vng --build

What do you think?

[arighi]

The change in the PR looks good to me. Thanks!

[matttbe]

Should we also force the update when --kconfig is used?

Hm... I'm not really convinced about this. I feel like we're going to break some workflows.

We would break it only for those launching vng --kconfig when a .config file already exists (and doing nothing then). But for me, there was no reason to launch this command doing nothing, probably the command was wrongly used :) (or the user expected it to do something, but didn't, a bit confusing?)

At this point I'd rather prefer to introduce a new --update-config option, that seems also more intuitive than using --kconfig to update the config.

In this way your example becomes more clear I think:

vng --update-config --config CONFIG ...
<change the config>
vng --build

What do you think?

I find it a bit confusing to have vng --kconfig doing nothing if the .config is present, but if you prefer having another option, I'm not against it, people can read the manual :)

[arighi]

Yeah, I'm almost convinced. Moreover looking at the help that we provide:

  --kconfig, -k         Only generate the kernel .config without
                        building/running anything

It seems pretty clear that --kconfig is supposed to re-generate the config, so I have to agree that doing nothing when the .config exists is a bit counter-intuitive.

Ok, feel free to update this PR or create a new one to do this change if you have time.

Thanks!

[matttbe]

It seems pretty clear that --kconfig is supposed to re-generate the config, so I have to agree that doing nothing when the .config exists is a bit counter-intuitive.

Good, thank you!

Ok, feel free to update this PR or create a new one to do this change if you have time.

Just did!