-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide local project filter in west config #653
Comments
Agree this is part of that general theme -- are you suggesting it's a dupe of any one of these in particular? This doesn't seem to quite fit any open issue. |
I thought it could have been, thanks for reviewing all existing issues and confirming it's not. |
Something that can be done today with a super-manifest, which achieves a relatively similar outcome, though each
which results in: Note this example is with a local manifest file, a similar solution can be achieved getting the manifest from a git repo as described by @mbolivar-nordic https://discord.com/channels/720317445772017664/733037524498382881/1100819756904366151 :
|
It's really strange and awkward to ask everyone to add a manifest layer on top of the default manifest to remove an opt-in that doesn't have to be stuffed in the default manifest in the first place. It would be so much simpler and more scalable to ask users of babblesim (or of any other opt-in) to drop their opt-in manifest in some predefined Compose by addition, not by stuffing+disable+re-add. Longer comment in the |
As an enhancement to west,
provide a new feature in which users can, thru local west workspace configuration, filter projects out of a manifest.
It could either be thru a deny-list or an allow-list (or both).
Motivation/Use case:
A user wants to track a project main manifest (e.g. Zephyr), but only needs for his work a subset of the projects that project manifest has.
The users wants/needs to save disk space, "west update" time and/or bandwidth. Yet he wants to jump back and forth in branches of that project. The user would prefer to avoid needing to create another project or super-manifest that includes the main project of interest as an import with an allowlist, as that requires extra steps (as he would like to jump between several branches, which are changing over time, he would need to keep updating/branching that super-manifest).
The user does not have any means to affect the project of interest to require it to add group filters, or some of the projects cannot be added to group filters (for ex. due to imports)
The workflow would be something like:
A user does a
west init
, after which (probably before a west update) he configures the project to filter in/out what he does want/not want (west config manifest.project-filter "-.*, +project_x, +project_y"
) . And then he does subsequent west updates, which just ignore the filtered out projects/all but the filtered-in projects.As an extension to this idea, so we would also cover the needs of #652 . In manifests projects definitions, allow a new key "default-inactive".
When a project has this key, the project is filtered out unless the local configuration project-filter enables it.
All other projects (without 'default-inactive') would be enabled by default unless the local configuration project-filter disables them.
There is no "default-active" key (it would be redundant).
Note: The project being filtered out means also a possible import done by that project is also ignored.
(Also, an imported manifest cannot define the same project and set "default-inactive : false", as the imported project with the same name is just ignored by west (this is the behavior already today)).
As a possible implementation (just to provide an understanding of a desired workflow and expected west behavior, not necessarily guide the solution):
The project-filter would be a list of projects names regexes, each preceded with "+" or "-".
When evaluating if a project is enabled or not, west would go thru this project-filter list from right to left. As soon as it finds the project name with a "-" it considers the project filtered out (and stops searching thru the list). As soon as it finds the project with a "+" , it considers it not filtered out (and stops searching thru the list).
The "default-inactive" key for <project_x> would be functionally equivalent to the list having as its left-most element -<project_x>
For extra users convenience, regex matches of the project name could be allowed. In this way, users could define a project filter like
"-.*, +project_x, +project_y"
(to disable everything but, project_x and y);or conversely
"+.*, -project_y"
to disable only project_y, but enable all other projects (even if they had a "default-inactive" key;or just " -project_y" to only disable "project_y" but let the rest as they would otherwise.
The text was updated successfully, but these errors were encountered: