Add "optional" keyword for given project in manifest
See original GitHub issueSometimes we have support projects for internal testing and internal resources in the manifest file. It can look like this:
projects:
- name: proj1
path: extra/project-1
revision: master
- name: proj2
path: internal_test/test
remote: secret_internal_repo
When customers get code they also get the manifest file. When they attempt a west init
or west update
, they will get an error since the internal_test repo is not accessible outside company firewalls.
We would like to se an “optional” argument for two reasons: 1: Give the customer a clear indication that this repo is not needed to build or use the application. 2: West can give a softer warning when this repo is not accessible. E.g.: West was unable to access secret_internal_repo. However, this project has been labeled optional.
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (4 by maintainers)
Top Results From Across the Web
Including files in source distributions with MANIFEST.in
Adding & removing files to & from the source distribution is done by writing a MANIFEST.in file at the project root.
Read more >repo Manifest Format - Google Git
Each remote element specifies a Git URL shared by one or more projects and (optionally) the Gerrit review server those projects upload changes...
Read more >Manifests | Android Open Source Project
The vendor manifest lists HALs specific to the product in the vendor ... combine the ODM manifest with the optional ODM manifest fragments....
Read more >Writing an Instrumentation Manifest - Win32 apps
Although the levels, tasks, opcodes, and keywords metadata are optional, you should use them to logically group or bucket the events. Grouping ...
Read more >vcpkg.json manifest files
Multiple optional features can be specified in manifest files, in the "features" object field. This field is a map from the feature name,...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think this is more about the README for users that might go either way
The expectation is indeed that the extra step would be necessary before using
closed_code
. (CI and other places that just need one-shot workspace setup can usewest update --gf=+group_closed
for brevity.)I personally don’t find the extra step too onerous, and I’m wary of the extra complexity that comes with adding a third state for projects. There were already unexpected consequences just adding a simple binary active/inactive:
https://github.com/zephyrproject-rtos/west/issues/491
I also got the interaction between imports and group filter wrong in v0.9.0 and had to break compatibility in v0.10.0 as mentioned here:
https://docs.zephyrproject.org/latest/guides/west/release-notes.html#v0-10-0
I’m therefore going to lean on the “conservative about features” design constraint for west, and say that I don’t think an explicit “optional” state is a good idea for now. I understand how that one use case could be made more convenient by that, but I don’t think it justifies the extra complexity by itself.