Clean way to import a west.yml's west commands but no submodule

[johnhatten2]

Context

I have a zephyr module containing drivers and unit tests. This module is normally used by some main application, but here, I need a pipeline (native_sim) to run my unit tests. The only thing west needs to import is Zephyr, along with its west commands. I don't want any of Zephyr's own submodules.

Documentation and experimentation reveals that a module's commands define in its west.yml MUST be imported via the import: key in the parent project's west.yml

Describe the bug

The bug is not being able to import a submodule west commands, while NOT importing the submodule's own submodules, in a clean way.

I found 2 workarounds and 2 fix proposals.

Workaround 1

This is what I'm currently using. We trick west by passing a non-existent projet in the name-allowlist.
Note : The string passed here could be literally anything, so writing "None" looks clean but it feels hacky.

projects:
  - name: zephyr
    revision: master
    import:
      name-allowlist:
        - None # Hack

Workaround 2

We could simply block all project manually, but this isn't clean either

projects:
  - name: zephyr
    revision: master
    import:
      name-blocklist:
        - acpica
        - babblesim
        - and
        - everything
        - else

Fix 1

I propose we allow name-allowlist to accept an empty list. Looks like the cleanest and most straightforward solution to me

projects:
  - name: zephyr
    revision: master
    import:
      name-allowlist: []

Fix 2

Maybe we should manage command import separately from project imports, or add a new import flag. There are a couple ways of doing this, I'll let you guys take care of that, but here's an example

projects:
  - name: zephyr
    revision: master
    import-commands: true # Could also be an allowlist

Repro steps

• Clone Zephyr's example application
  git clone https://github.com/zephyrproject-rtos/example-application.git && cd example-application
• Remove the project imports in west.yml (cmsis, hal_nordic, hal_stm32)
• Init the workspace
  west init --local --mf west.yml && west update (should pull only Zephyr)
• Modify the example application to make it compatible with native_sim (a simple hello_world should do it)
• Upon issue resolution, we should be able to run :
  west build -p -b native_sim app -t run

[marc-hb]

Hi @johnhatten2 !

This looks interesting but I'm afraid you posted it in the wrong place.

• It's not obvious but west tries to be as independent of Zephyr as possible and your description seems to refer to Zephyr a lot? If you can reproduce the problem without Zephyr then by all means please share that step-by-step reproduction here in a new west issue here.

• Even if you had filed this in https://github.com/zephyrproject-rtos/zephyr/issues, GitHub issues are focused on solving just one specific issue: either one specific feature or one specific bug. All the trial and error and long way you got there can be interesting but that shouldn't come first in the description. If you click on the green "New" button at https://github.com/zephyrproject-rtos/zephyr/issues you will get templates demonstrating this.

So maybe you should first discuss this in one of the Discord channels, or at https://github.com/zephyrproject-rtos/zephyr/discussions? Maybe take a look at https://github.com/zephyrproject-rtos/west/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Partial%20imports%22 and also search other places.

Finally, avoid screenshots: https://docs.zephyrproject.org/latest/develop/getting_started/index.html#use-copy-paste

[pdgendt]

The example might be about Zephyr, but the issue is related to west and originates from discord.

[marc-hb]

Another important practice when filing issues: mention relevant context when any.

I still think this issue looks like brainstorming, is off to a bad start and that it would be better to file a new issue and forget about this one. If not, then rewrite the description following one of these templates: https://github.com/zephyrproject-rtos/zephyr/tree/main/.github/ISSUE_TEMPLATE

So what is the concise problem statement and/or objective? name-allowlist: [] should work? Or finding a better alternative? Documentation updates? Others?

[johnhatten2]

@marc-hb Thanks for the guidance, I took the time to investigate further a grey zone that leads nowhere, which I took out completely from the post, and I cleaned the rest.

Hopefully this is more acceptable and clear now

[marc-hb]

Thanks for the big cleanup, so much more readable now! Sorry I hastily closed this.