Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

commands: Show less generic error when no manifest is loaded #671

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

57300
Copy link

@57300 57300 commented Jun 2, 2023

Minor quirk that stuck out to me while testing the recent changes. Before 23db6e1, if I were to try west manifest --resolve in Zephyr without cloning bsim, I would see this:

FATAL ERROR: project bsim (tools/bsim): cannot import contents of west.yml; do you need to run "west update"?

which is helpful enough. Now, this generic message gets displayed:

FATAL ERROR: can't run west manifest; it requires the manifest, which was not available. Try "west manifest --validate" to debug.

Ironically, west manifest --validate produces the same error, which is not very helpful. So, I tried to fix that.

If loading the manifest fails, running a command which needs to read the
manifest could result in this being shown:

   FATAL ERROR: can't run west manifest; it requires the manifest, which
   was not available. Try "west manifest --validate" to debug.

In this case, trying "west manifest --validate" would also display the
same error, which is not very helpful.

Instead of that, west can print the deferred error from load_manifest(),
which contains a more specific message. Rework the WestCommand.manifest
property handling by adding a dummy _ManifestRequired exception. It is
caught by run_builtin() in main.py, which can access the stored error.

Signed-off-by: Grzegorz Swiderski <[email protected]>
@57300
Copy link
Author

57300 commented Jun 2, 2023

@mbolivar-nordic Hi, I can't add you as reviewer, but do you want to look over this?

Copy link
Contributor

@mbolivar-nordic mbolivar-nordic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should probably be handled in the relevant built-in commands themselves by checking WestCommand.has_manifest and erroring out as necessary. Did you consider this? If so, why did you reject it?

@57300
Copy link
Author

57300 commented Jun 2, 2023

I think this should probably be handled in the relevant built-in commands themselves by checking WestCommand.has_manifest and erroring out as necessary. Did you consider this? If so, why did you reject it?

Yes, I had briefly considered it, but I figured it would probably involve passing WestApp.mle to each command, so that it could still report why not self.has_manifest. I decided against it, thinking it might be better to have common handling in one place. There's already some common handling in handle_builtin_manifest_load_err(), which seems to cover quite a few cases.

I'm fine with per-command handling, if you prefer, since it looks like only west manifest needs it right now anyway.

In fact, on second thought, the easiest fix for west manifest specifically might be to just remove it from this list:

west/src/west/app/main.py

Lines 277 to 283 in 9e8f500

# A few commands are always safe to run without a manifest.
# The update command is sometimes safe and sometimes not, but
# we need to include it in this list because it's the only way
# to fix a manifest-rev revision in a project which is being
# imported to point from a bogus manifest to a non-bogus one.
no_manifest_ok = ['help', 'config', 'topdir', 'init', 'manifest',
'update']

since it will always bail without a manifest:

def do_run(self, args, user_args):
manifest = self.manifest

@marc-hb
Copy link
Collaborator

marc-hb commented Aug 30, 2024

bsim seems to have been made optional now by Zephyr commit f30f08a3ce75 and enabling babblesim in the project-filter now fails with FATAL ERROR: "west manifest --resolve" is not (yet) supported when the manifest.project-filter option is set. So I'm no sure it's possible to reproduce the original issue upstream.

However I tried with a totally different project and as of the current west version 0612a6d the issue does not seem to have changed.

Considering Marti left the project, I have successfully tested a much simpler and zero-risk "fix" similar to 45762a0

diff --git a/src/west/app/main.py b/src/west/app/main.py
index 2b4addb03e2d..b678893911f1 100755
--- a/src/west/app/main.py
+++ b/src/west/app/main.py
@@ -917,7 +917,7 @@ class WestArgumentParser(argparse.ArgumentParser):
                     # warn them again.
                     append('Cannot load extension commands; '
                            'help for them is not available.')
-                    append('(To debug, try: "west manifest --validate".)')
+                    append('(To debug, try: "west -vv manifest --validate".)')
                     append('')
             else:
                 # TODO we may want to be more aggressive about loading
diff --git a/src/west/commands.py b/src/west/commands.py
index 2e5a4b89b555..1abb0fcd17d2 100644
--- a/src/west/commands.py
+++ b/src/west/commands.py
@@ -260,7 +260,7 @@ class WestCommand(ABC):
         if self._manifest is None:
             self.die(f"can't run west {self.name};",
                      "it requires the manifest, which was not available.",
-                     'Try "west manifest --validate" to debug.')
+                     'Try "west -vv manifest --validate" to debug.')
         return self._manifest

     def _set_manifest(self, manifest: Optional[Manifest]):

marc-hb added a commit to marc-hb/west that referenced this pull request Sep 12, 2024
It seems natural to recommend "debug" flags when telling the user to
"debug".

More specifically, this makes a big difference in situations like the
one reported in zephyrproject-rtos#671

Signed-off-by: Marc Herbert <[email protected]>
@marc-hb
Copy link
Collaborator

marc-hb commented Sep 12, 2024

Minor -vv mitigation patch submitted in #734

EDIT: merged.

@pdgendt pdgendt added this to the v1.3.0 milestone Sep 13, 2024
marc-hb added a commit that referenced this pull request Sep 16, 2024
It seems natural to recommend "debug" flags when telling the user to
"debug".

More specifically, this makes a big difference in situations like the
one reported in #671

Signed-off-by: Marc Herbert <[email protected]>
@marc-hb
Copy link
Collaborator

marc-hb commented Sep 17, 2024

This change is located in a fairly complex area little or no test coverage: error handling.

I don't have the time to learn about it but I don't think the value is worth the risk. My 2 cents, sorry.

@pdgendt
Copy link
Collaborator

pdgendt commented Sep 18, 2024

I'll move it out of the 1.3 list for now.

@pdgendt pdgendt removed this from the v1.3.0 milestone Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants