Improve inspect-builder output

[dwillist]

• by default show all id/version information for nested buildpacks
• allow a '--depth' or '-d' flag to truncate this nesting at a configurable depth
• clean up the 'Buildpacks:' list to omit repetitions with the same buildpack id and version

Signed-off-by: dwillist dthornton@vmware.com

Summary

This lets the inspect-builder subcommand recursively list all group and buildpack information for a builder.
The old behavior can still be achieved with pack inspect-builder --depth 1

Additionally updates the inspect-builder output under Buildpacks: to omit repetitions.

Output

Before

We did not display Detection Order information for metabuildpacks.

Buildpacks:
  ID                           VERSION                             HOMEPAGE
  read/env                     read-env-version
  noop.buildpack               noop.buildpack.version
  noop.buildpack               noop.buildpack.later-version        http://geocities.com/cool-bp
  simple/layers                simple-layers-version
  simple/nested-level-2        nested-l2-version
  simple/nested-level-1        nested-l1-version
  read/env                     read-env-version

Detection Order:
  Group #1:
    simple/nested-level-1
    read/env@read-env-version                      (optional)

After

We can display Detection order to the desired depth using --depth flag, omission displays everything. Additionally the read/env buildpack entry is no longer repeated.
Example

pack inspect-builder <builder-name>

Buildpacks:
  ID                           VERSION                             HOMEPAGE
  read/env                     read-env-version
  noop.buildpack               noop.buildpack.version
  noop.buildpack               noop.buildpack.later-version        http://geocities.com/cool-bp
  simple/layers                simple-layers-version
  simple/nested-level-2        nested-l2-version
  simple/nested-level-1        nested-l1-version

Detection Order:
  Group #1:
    simple/nested-level-1
      Group #2:
        simple/nested-level-2@nested--version
          Group #3:
            simple/layers@simple-layers-version
            read/env@read-env-version
    read/env@read-env-version                      (optional)

Example using the --depth flag

pack inspect-builder <builder-name> --depth 2

Detection Order:
  Group #1:
    simple/nested-level-1
      Group #2:
        simple/nested-level-2@nested-l2-version
    read/env@read-env-version                      (optional)

Documentation

This will require documenting the new --depth flag that can be passed to inspect-builder

• Should this change be documented?
  • Yes (additions to this PR coming)
  • No

Related

Resolves #253

[codecov]

Codecov Report

Merging #769 into main will increase coverage by 0.20%.
The diff coverage is 85.04%.

@@            Coverage Diff             @@
##             main     #769      +/-   ##
==========================================
+ Coverage   74.76%   74.96%   +0.20%     
==========================================
  Files          77       77              
  Lines        5174     5274     +100     
==========================================
+ Hits         3868     3953      +85     
- Misses       1001     1011      +10     
- Partials      305      310       +5     

Flag	Coverage Δ
#os_linux	77.39% <86.67%> (+0.14%)	⬆️
#os_macos	73.39% <86.67%> (+0.22%)	⬆️
#os_windows	73.27% <85.04%> (+0.23%)	⬆️
#unit	74.96% <85.04%> (+0.20%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[dfreilich]

This is really great, thanks for the PR! I have a few nits and comments, but overall this is 🏅

One general question - looking at this, it's interesting that a lot of the legwork for inspect_builder happens in internal/commands, which seems to buck the normal trend of having it be part of the public API. I wonder what people think of moving this functionality to the public inspect_builder.go file.

[jromero]

@dwillist sorry for the delay in reviewing this. Based on the output from the description of this issue I have two questions.

1. I know we've discussed moving over to a tree structure. I think, visually, that would be easier to digest. Here's an example from maven of what I would envision. Is there a reason why we can't or shouldn't move over to a tree structure?
2. (Doesn't matter if we make it a tree structure). The Group # appear to be incremental as you nest. I would think that they are only incremental for their "level". For example, I expected something like:

Detection Order:
  Group #1:
    simple/nested-level-1
      Group #1:
        simple/nested-level-2@nested--version
          Group #1:
            simple/layers@simple-layers-version
            read/env@read-env-version
          Group #2:
            simple/layers-2@simple-layers-version
            read/env-2@read-env-version
    read/env@read-env-version                      (optional)

[jromero]

Thanks @dwillist for this! I'm sure some buildpack users (and authors) are going to be very happy with it. :D

I made a few tweaks to it in a separate PR #795. Feel free to review the changes but once that PR goes in this one will too.