Currently, including a package deployment with a missing resource dependency on a network service (e.g. as in https://github.com/ethanjli/rpi-forklift-demo?tab=readme-ov-file#modify-a-pallet-safely) can cause plt check/plt stage to print a very long and rather unhelpful error report about package deployments providing the most similar resources (essentially all other package deployments with network services get printed out). Here are some ideas for cleaning up this input:
Limit the list of candidate resources to ~5 candidates, and sort them by similarity of unmatched criteria (e.g. string similarity)
Consider disabled package deployments as candidates for meeting resource requirements, especially if they match (or are very similar) to the unmatched resource criteria
Consider disabled feature flags as candidates for meeting resource requirements, especially if they match (or are very similar) to the unmatched resource criteria
Consider packages available in required repos as candidates for meeting resource requirements, even if they don't have an enabled/disabled package deployment associated with them
Allow packages' resource requirement objects to include a list of suggested packages (and maybe associated feature flags); then that list will be prioritized, and all candidates in that list will be displayed. If a suggested package is provided by an unknown repo (i.e. a repo which is not among the pallet's requirements), we don't need to show any details about it.
Currently, including a package deployment with a missing resource dependency on a network service (e.g. as in https://github.com/ethanjli/rpi-forklift-demo?tab=readme-ov-file#modify-a-pallet-safely) can cause
plt check/plt stageto print a very long and rather unhelpful error report about package deployments providing the most similar resources (essentially all other package deployments with network services get printed out). Here are some ideas for cleaning up this input: