Spurious Error: "zephyr-no-west/samples/hello_world" is not in a west installation

[marc-hb]

To Reproduce
Steps to reproduce the behavior:

1. Have (at least) two zephyr clones: one created with the west tool + the other without west
2. Define ZEPHYR_BASE=/path/to/zephyrnowest and try to build samples/hello_word (or anything else) in zephyrnowest while west is in PATH

Expected behavior
Everything builds without any error

Impact
(hopefully? )minor: confusing error message

Screenshots or console output

Error: "/home/user/zephyrnowest/samples/hello_world" is not in a west installation.
Things to try:
 - Set ZEPHYR_BASE to a zephyr repository path in a west installation.
 - Run "west init" to set up an installation here.
 - Run "west init -h" for additional information.

Then everything seems to build as usual (can someone confirm?)

Environment (please complete the following information):
Linux Fedora
Reproduced with either zephyr-0.9.5 or "host"
v1.14.0-rc1-849-g35b7fde8a60b

Additional context
workaround: pip3 uninstall west

[mbolivar]

workaround: pip3 uninstall west

Another workaround if you want to use Zephyr with and without west on the same computer is to install west in a virtualenv. I always do Zephyr development in a Python virtualenv anyway, because it wants such exact versions of all the dependencies that I don't want to have it interfering with my --user site packages.

For managing virtualenvs I recommend:

https://virtualenvwrapper.readthedocs.io/en/latest/
https://pypi.org/project/virtualenvwrapper-win/

[mbolivar]

I'm a bit torn about whether to mark this an 'enhancement' or a low priority bug. @carlescufi, @tejlmand, what do you think?

[marc-hb]

I always liked the subtitle of the "bug" label: "when things don't work as expected". It's nice because it's orthogonal to other things like severity and priority.

So I think your question can be rephrased like this: is this "dual" use case meant to be already supported or not?

[ulfalizer]

This one bit me too, after I installed west to try out a fix with some Nordic stuff (in a separate directory) and then went back to main Zephyr.

Definitely feels like a bug to me. I think it would be best to not check for a west installation within the main CMake files (if that's what's going on), and keep it as a separate layer instead. Too tangled up.

[mbolivar]

always liked the subtitle of the "bug" label: "when things don't work as expected". It's nice because it's orthogonal to other things like severity and priority.

OK, then I'm marking this low priority, since

1. it will only affect users who have west installed and thus presumably won't be too surprised if a monorepo zephyr installation behaves a bit strangely
2. a workaround (install west in a virtualenv) is available that avoids the error message

@ulfalizer @marc-hb @carlescufi @tejlmand please speak up if you disagree with this.

I think it would be best to not check for a west installation within the main CMake files (if that's what's going on), and keep it as a separate layer instead. Too tangled up.

The CMake files absolutely must check for a west installation in order to decide whether or not to use west list to get a list of candidate projects to use as Zephyr modules, so this suggestion makes no sense.

[andrewboie]

what is the final, intended scope of west?
It used to be an abstraction layer for flashing, then it migrated to a tool like google's repo for checking out code, and now it's being integrated into how we build the kernel itself.

[marc-hb]

I'm marking this low priority bug

Looks good as long as this message is really just a spurious message than can be safely ignored and not the sign of some non obvious side-effect(s) that I haven't discovered yet. Can you confirm @mbolivar ?

now it's being integrated into how we build the kernel itself.

Not sure what you mean @andrewboie

[andrewboie]

now it's being integrated into how we build the kernel itself.

Not sure what you mean @andrewboie

cd samples/hello_world
west build --board=qemu_x86

[carlescufi]

@mbolivar I agree with this being a low-prio bug, feels exactly like that.

[ulfalizer]

This wasted quite a lot of time for me, so for me it's more than a low-prio. Apparently it hit other people too.

In general, I think we should strive towards integrating the flashing helpers and the like into the main repo. West shouldn't be the thing that takes over because it's tangled up in everything and can't be cleanly separated. That's a bad way to do it.

Small and independent easy-to-understand helpers are superior to blobby framework stuff.

[carlescufi]

Hi @andrewboie

what is the final, intended scope of west?
It used to be an abstraction layer for flashing, then it migrated to a tool like google's repo for checking out code, and now it's being integrated into how we build the kernel itself.

The scope was the set at the beginning of its development and it has never changed since. West was always going to be a meta-tool that would handle:

• Building (optionally)
• Flashing
• Repo management

Please see this issue created a year ago: #6205
It was used for flashing since (almost) the beginning but that was just because the rest of the features were not ready.