Background
The snapcraft CLI’s entire purpose is to orchestrate multiple parts into a cohesive unit of distribution. Oftentimes, several of these parts are dependencies with which the developer is not tremendously familiar. As a result, it’s easy to get into the situation where multiple parts are supplying the same library in different places, or more generically, there is SOME FILE throwing things off in the snap, and the developer has no idea where it came from (i.e. which part is supplying it). This leads to nasty find session, crawling the tree of each part trying to find that same file.
Proposal
The snapcraft CLI actually already knows this information due to its state tracking, it just needs to grow a way to be asked for it. The proposal is to add a new subcommand to the snapcraft CLI:
snapcraft provides <file path>
This command only has meaning for the stage and prime steps (otherwise the files are still in part-specific directories), which just so happen to have their own directories. So if <file path> is in the staging area, the snapcraft CLI checks the stage state of each part to determine which part provided it. If <file path> is in the priming area, the snapcraft CLI checks the prime state of each part to determine which part provided it.
Caveats
There is two main limitation to this. First of all, the state tracking in the snapcraft CLI is not fool-proof. It can’t track operations done by scriptlets (which are just shell scripts that can do essentially anything), so for snaps making heavy use of them, this feature may not be particularly useful.
Second, this feature does nothing if the snap has already been built and one no longer has access to the snapcraft CLI’s build artifacts (e.g. after a cleanbuild). It’s meant for debugging while building a snap in iteration, running locally.