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

[marc-hb]

From a digression in #518.

To please everyone and provide a good "out of the box" experience, west manifests can have many repos that are unnecessary to most users. As a random example, out of the 45-ish projects currently in https://github.com/zephyrproject-rtos/zephyr/blob/main/west.yml I need only 2 right now. So to save disk, network and time I never ever ran west update and never downloaded more than these 2 repos. Instead I always west update proj1 proj2. This also makes west status much shorter and readable (similar to #518, which solves a different problem).

west update proj1 proj2 works but it is inconvenient. First because you have to remember to never ever run west update, then because the real command is actually west update dir1/dir2/what_was_that_name_again? So it would be nice to have to run west update dir1/dir2/what_was_that_name_again? only the first time and then run just west update --if-present. Even better: have if-present in west config and then just west update.

[marc-hb]

From @mbolivar-nordic in #518

I think that since west status already ignores inactive projects by default, and the upstream zephyr manifest now has groups, you may have the ingredients for most of what you want already by just cloning a subset of active projects.

I will look into that but I suspect a if-present in west config would beat groups from a convenience perspective. If/when that setting exists then I would for sure permanently add it once to my global user config and never touch it again (which means some --no-if-present CLI option would be useful to override the config on rare occasions)

[mbolivar-nordic]

Thanks for filing a feature. I'd like to start to clarify some behavior around imports.

Here are a few simple cases.

1. I have project A in my main manifest file, and I have import: true for project A. A is cloned in my workspace. A/west.yml defines projects B and C, which are not cloned.
2. I have A and B cloned, but not C.
3. I have B cloned, but not A or C.

What does west update --if-present do in each case? I think these would be the "least surprising" outcomes:

1. A is updated
2. A and B are updated
3. Nothing is updated (maybe a little surprising actually!)

[marc-hb]

Yes I agree with 1. 2. and 3. In other words imports should be treated as much as possible if they were inlined instead, I hope that's what you meant.

Except in case 3. where west has no access to A/west.yml hence cannot possibly know that B is part of anything and no way to tell it could update it. Could be a bit surprising at first but very logical once the user spends 5 seconds thinking about it.

[mbolivar-nordic]

OK, thanks. Sketching out an implementation then, as prep work we would need:

• a new ImportFlag.FORCE that asks the Manifest constructor to call importer on every single import statement
• support for it in the Manifest import machinery

Then west update --if-present would need to:

• pass ImportFlag.FORCE to the Manifest constructor
• pass an importer callback which returns None if the project is not cloned

Plus any other unanticipated changes I can't think of yet.

Think you can take a crack at it?

[mbolivar-nordic]

Additionally, I think --if-cloned might be a better name than --if-present, to parallel the west.manifest.Project.is_cloned API function that would be used to make the decision.

[mbolivar-nordic]

Hm, on second thought, we might be able to get away with just using the existing ImportFlag.FORCE_PROJECTS, but I'm not totally sure.

[tejlmand]

Why not a simple: west config update.projects -- +projectA,+projectB

and if those are set, then a clean west update will only update those particular project, just a if west update projectA projectB was executed.

This also follows how groups are enabled and disabled, and it would still allow a user to specifically invoke:
west update projectEvaluateThis

if they temporary wants to update a specific project and not wanting to add it to the list.

[marc-hb]

It's more tedious and less dynamic to hardcode the list of projects of interest. It's simpler to dynamically west update new_interest or rm -rf not_interested_anymore and done.

If this feature is ever available I will turn it on at the global user level, not just per workspace. If there were no backward compatibility concern I would even argue it should be the default (it is the default for submodules and maybe others).

In fact #518 is a bit of a mitigation for this (not just)