Allowlist on an imported project propagates to deeper project imports

[nmunnich]

Say that you have a series of projects:

• Project A, which imports projects B and X_1, ... , X_n. Project A is structured such that it is usable with any of its projects individually.
• Project B, which imports project C. Project B has project C as a strict dependency and will not work if it is not present.

Now say you want to add project A to your project using a west manifest. Say that you then decide that, due to the large size of the various things project A imports, you want to only import project B as the rest are irrelevant to you.

manifest:
  projects:
  - name: a
    url: a-url
    import:
      name-allowlist:
      - b

The allowlist will propagate down, preventing project B from importing project C and thus rendering it non-functional.

I'm not sure whether this should be considered a bug or "works as intended". If the latter, I would very much like to have an additional option that can be applied to prevent the allowlist from propagating down, e.g. shallow-allowlist: true.

I have a test demonstrating this issue here: 739ec78

[marc-hb]

I'm not sure whether this [allowlist behavior] should be considered a bug or "works as intended".

I don't know either, but I think the core issue lies in what Project A is:

Project A, which imports projects B and X_1, ... , X_n. Project A is structured such that it is usable with any of its projects individually.

Such "inventory/catalog" projects should simply not exist in the first place. projects: should be carefully selected, actual dependencies, not long lists of "Look at all the cool things you can do with me!"

When such catalogs hijack the dependency system to exist for "deceptive convenience", then production projects should not depend on the former.

And yes: Zephyr is too much like this. It's trying to get better but those things take time:

• Review optional modules and make them external zephyr#91061

When you don't depend on a "big catalog", then you never have to use name-allowlist: to include a small subset and reject all the rest. Instead, you selectively exclude the reasonably small list of features you don't need. This avoids recurring requests to make things smaller like the recent:

• https://docs.zephyrproject.org/latest/develop/getting_started/index.html support custom minimal installation zephyr#108783 (comment)

Also, firmware projects should use an SBOM to actively manage dependencies and never be surprised by changes there:
https://fosdem.org/2026/schedule/event/ZXJD8E-sboms_for_embedded_firmware_the_zephyr_rtos_case_study/

Finally, feature selection should have one layer of indirection and be "group-based" instead of fiddling with lower level implementation details like project names:

• https://docs.zephyrproject.org/latest/develop/west/manifest.html#west-group-filter-imports

---

cc: @mbolivar, @kartben

• Test fixed group filter semantics #481 important and possibly relevant import design change in 2021

[nmunnich]

Such "inventory/catalog" projects should simply not exist in the first place. projects: should be carefully selected, actual dependencies, not long lists of "Look at all the cool things I can do!"

While I understand the rationale behind this statement, I don't fully agree with it. Nowhere can I find statements which imply anything of the sort for west - west is a meta-tool to manage Git repositories, and has the capabilities to support such catalogue projects. Whether a catalogue project is a good idea or not depends on the exact situation.

It is true that a group-based approach can work, if the project in question is setup for it. I feel as though there is likely some scenario where groups will fail where allowlist would succeed, but group-based approaches should indeed be the primary way to do filtering - though there are certainly scenarios where allowlist would be simpler.

Considering the "Conservative about features" design constraint, I'm happy to have this marked as a "bug?" report and be discarded if decided that this interaction is desired - on thinking it over I think I would consider this a "bug" personally, but it's certainly not obvious.

[nmunnich]

For reference, because I just discovered this issue, my personal use case is something similar to zephyrproject-rtos/zephyr#98368 - using allowlist makes it easier to work on and reason about, but groups would also work.

[marc-hb]

While I understand the rationale behind this statement, I don't fully agree with it. Nowhere can I find statements which imply anything of the sort for west - west is a meta-tool to manage Git repositories, and has the capabilities to support such catalogue projects. Whether a catalogue project is a good idea or not depends on the exact situation.

Fair enough. I think https://docs.zephyrproject.org/latest/develop/west/why.html tends to lean more on the "actual dependencies" side but I agree that west alone is essentially just a tool to manage git repos and it tries hard not to be more than that ("conservative about features"). So: catalogues why not!

But it is still a design mistake to import such an entire "catalogue"/world like it were a normal dependency - and then wonder why it's difficult and painful to filter out all the unwanted stuff. "Doctor, it hurts when I do this..." Such a mistake is not west-specific. Catalogue or list of dependencies? Manifest writers must make up their mind and clearly express their intention. Unfortunately, manifests are part of build systems which are universally hated, they are not easy to do and no one ever got rewarded for designing and/or maintaining a manifest. So I bet manifests suck more often than not.

my personal use case is something similar to

• Zephyr Module Registry for community modules zephyr#98368

Very relevant and useful reference, thanks for the link!