pack buildpack package fails when using [[targets]] with ERROR: no compatible stacks among provided buildpacks

[edmorley]

Summary

When I use pack buildpack new with default options, the resulting generated buildpack fails to package with pack buildpack package.

Whilst the error can presumably be fixed by passing additional --targets options to pack buildpack new, I feel like the defaults should at least "just work" when immediately packaged on the same machine as that which generated the new buildpack.

---

Reproduction

Steps

1. pack buildpack new test-buildpack
2. pack buildpack package --verbose --path test-buildpack/ --format file test-buildpack.cnb

Current behavior

$ pack buildpack package --verbose --path test-buildpack/ --format file test-buildpack.cnb
Downloading buildpack from URI: file:///Users/emorley/src/test/test-buildpack
ERROR: no compatible stacks among provided buildpacks

$ cat test-buildpack/buildpack.toml
api = "0.8"
WithWindowsBuild = false
WithLinuxBuild = false

[buildpack]
  id = "test-buildpack"
  version = "1.0.0"

[[targets]]
  os = "darwin"
  arch = "arm64"

Expected behavior

For the pack buildpack package command to succeed with no error.

---

Environment

pack info

$ pack report
Pack:
  Version:  0.33.0+git-e3f8bc2.build-5475
  OS/Arch:  darwin/arm64

Default Lifecycle Version:  0.18.4

Supported Platform APIs:  0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12

Config:
  default-builder-image = "[REDACTED]"
  experimental = true

  [[trusted-builders]]
    name = "[REDACTED]"

  [[trusted-builders]]
    name = "[REDACTED]"

docker info

N/A

[edmorley]

This bug is blocking us from being able to publish heroku/procfile, which has just been upgraded to Buildpack API 0.10, and has [[targets]] in buildpack.tomk instead of [[stacks]]:
https://github.com/heroku/procfile-cnb/actions/runs/8025023370/job/21924849039#step:4:10

It appears the validation error goes away if I add back an empty [[stacks]] table (the table doesn't even need the old stack id key to be present).

[edmorley]

I've updated the issue title to make this clearer that this is a general bug in pack buildpack package and not something specific to pack buildpack new - since the buildpack generated by the new subcommand is valid, it's the packaging processes handling of such buildpack.toml files in general that's broken.