Dependency selection is inconsistent across commands
Description
Currently, various bst commands accept the option -d
/--deps
to select additional dependencies of a specified element. In most cases, the option is treated as a PipelineSelection and passed to a Stream method.
However, the actual values that are accepted by the command varies:
Command | none | all | run | build | plan |
---|---|---|---|---|---|
show | X | X | X | X | X |
source fetch | X | X | X | ||
source track | X | X | |||
source checkout | X | X | X | X | |
artifact checkout | X | X | X | ||
artifact pull | X | X | |||
artifact push | X | X | |||
build (effective*) | X | X |
* The current behaviour supported by the command, despite it not accepting --deps
. See #1078 (closed).
Further, PipelineSelection.PLAN seems to arbitrarily be based on the ALL selection. The current behaviour of Pipeline#get_selection(el, PipelineSelection.PLAN)
is to choose the union of:
- the runtime dependency subtree of el
- the build dependency subtree of el, pruned at any cached elements
The fact that the runtime deps are included seems arbitrary to me; for example, a user may wish to only fetch the sources of uncached build dependencies, but cannot with the current behaviour.
Proposed changes
- Alter all relevant commands to accept
--deps
followed by a choice of Scope: all, build, run, or none. (The artifact commands will only be able to meaningfully use these after work is done towards #1103 (closed).) - Depending on the most sensible default behaviour, add a new option to each of such commands which specifies whether or not to prune cached elements from the constructed build dependency tree. For example, this might be called
bst build --rebuild
(to not prune), orbst show -d all --prune-built
(to prune).
To implement this it might make sense to remove PipelineSelection entirely and replace it with an extra boolean argument Element.dependencies which describes whether to prune... if this is indeed possible.
I would love to hear your opinions on this issue; I know it's low-priority but I think it would make the UI clearer.