Revisit modules and inclusion in the default manifest

[mbolivar-nordic]

Problem statement: zephyr/west.yml contains "optional" modules that not everybody needs or wants. As a project, we want to choose a process for adding these optional modules without forcing all users to clone them when they run "west update".

[mbolivar-nordic]

@mbolivar-nordic to summarize options and see if there's momentum

[stephanosio]

#46105 (comment)

[mbolivar-nordic]

To present in the process WG today: https://docs.google.com/presentation/d/1txIGpbDz8tr_86xokgtNisTjzASwWT0f6Eho8zEFfOw/edit?usp=sharing

[mbolivar-nordic]

Process WG:

• @mbolivar-nordic proposes using group-filter to control the size of the default manifest
• Greg Shue: thinks this is asking the wrong question
• @stephanosio: other options include adding a package manager for zephyr, but nobody is able to work on this at this time, so this is a viable option
• @dleach02 I would propose adding all HALs to the set of projects that aren't cloned by default
• @nashif one thing we could do is have a declaration of your dependencies in your CMakeLists.txt
• @stephanosio another idea is using kconfig, since we are moving all module kconfig to zephyr
• greg shue: the problem with that is it isn't friendly to downstream-only modules since it would require modifications to zephyr
• @stephanosio the downstream workspace can define their own kconfigs outside of the zephyr tree
• @nashif can we somehow add a dependency on a kconfig variable that would result in a clean build error due to a missing module?
• greg shue: do you mean an error with instructions for how to fetch the module, or automatic fetching of the module in the build system?
• @nashif it could be done either way; I would say automatically fetching the module in the build
• @stephanosio how to do this? we don't mandate west. I guess we could print an error with instructions for west when west is available, and fall back on another error message about the missing module if west is not being used.
• greg shue: I need the build to fail because I don't want to automatically pull modules that I haven't vetted
• @nashif I think we can start with the proposal to filter out groups by default, and build on top with some extra prototyping

Conclusion is to propose using group filters for new "optional" modules and potentially existing modules on a case by case basis. It will be up to whatever pull requests follow from this to determine the details of what is and is not optional.

[marc-hb]

In our CI we need only two git repos / "modules". We have a very low-tech and very efficient solution:

west init
west update module1 module2

It has been working perfectly. It would be perfect in interactive use too... except for this missing, related and already discussed west feature: west update --if-present

• [FEATURE] west update --if-present (better name wanted) west#519

... where --if-present can be made persistent in some config file.

I think git submodules update works like this. I suspect git-repo does too.

The non-scalable workaround is to never use a bare west update and not forget to west update module1 module2 every time instead.

[mbolivar-nordic]

Conclusion is to propose using group filters for new "optional" modules and potentially existing modules on a case by case basis. It will be up to whatever pull requests follow from this to determine the details of what is and is not optional.

There's nothing to do here anymore from a process perspective as the answer to the initial question are now down to technical details. I'm closing this. If we have additional process questions related to this area, we will need a new issue.