Confusing `No buildpacks found!` error message when `buildpack.toml` parsing fails

[joshwlewis]

When trying to package a buildpack with an invalid toml, this is the messaging:

▹ cargo libcnb package                                                                                                                  130 ↵
🚚 Preparing package directory...
🖥️ Gathering Cargo configuration (for x86_64-unknown-linux-musl)
🏗️ Building buildpack dependency graph...
🔀 Determining build order...
❌ No buildpacks found!

In my case, it wasn't finding any buildpacks, because my buildpack.toml had [[stacks]] in it. While stacks is deprecated, it is still supported in Buildpack API 0.10 (https://github.com/buildpacks/spec/blob/7eb38d15fd3bd5bb5240584f0e70beb61913032c/buildpack.md?plain=1#L1143). Maybe there are two issues here:

1. Instead of reporting no buildpacks found, maybe we could report that we found a buildpack.toml that wasn't correct?
2. Maybe we should still support [[stacks]] in buildpack.toml, even if libcnb.rs ignores it? This is likely only a temporary issue, so I could go either way here.

[edmorley]

The error message comes from: https://github.com/heroku/libcnb.rs/blob/e9072af1b71bfcd23ac8cf70f3620299a7eebaef/libcnb-cargo/src/package/error.rs#L25-L26 https://github.com/heroku/libcnb.rs/blob/e9072af1b71bfcd23ac8cf70f3620299a7eebaef/libcnb-cargo/src/package/command.rs#L84-L86

Which implies that an earlier failed parsing error wasn't propagated, and instead the buildpack ignored/excluded from the dependency graph.

I think this might have the same root cause as #708.

[iloverink]

This also causes some confusion when using pack package against the packaged output of cargo libcnb package. The pack outputs the following error

ERROR: no compatible stacks among provided buildpacks

Adding [[stacks]] id = "*" seems to address that, but then I get this error from cargo libcnb package.

[edmorley]

@iloverink Hi! What version of Pack CLI is that using?

[iloverink]

Hi @edmorley - 0.33.2+git-f2cffc4.build-5562 installed from the homebrew tap

[joshwlewis]

This area is also problematic for https://github.com/heroku/languages-github-actions, which depends on libcnb-data for buildpack.toml parsing. It forces languages-github-actions to use libcnb-data 0.17.0 (so that buildpacks with [[stacks]] are supported), or libcnb-data 0.18.0 (so that buildpacks with[[targets]]] are supported). There isn't a parser that supports both, even though both are allowed in the Buildpack API 0.10 spec.

More about this over on https://github.com/heroku/languages-github-actions/issues/199.

[edmorley]

The comments in this issue so far have actually been about three separate things:

1. That cargo libcnb package gives a confusing No buildpacks found! error message if buildpack.toml parsing fails.
2. That libcnb-data would fail to parse a buildpack.toml that contained [[stacks]] even though the spec for Buildpack API 0.10 permits it.
3. That Pack CLI's pack buildpack package has a bug that means it still requires [[stacks]] even if [[targets]] is specified, and otherwise fails with ERROR: no compatible stacks among provided buildpacks.

Issue (2) has been fixed by #789 and released in libcnb 0.19.0.

Issue (3) is an upstream Pack CLI bug unrelated to libcnb, for which I've filed: https://github.com/buildpacks/pack/issues/2047

This leaves just (1) as something we should improve in libcnb. As such, I've adjusted the issue title to be about just (1).

It's also quite likely that (1) is a duplicate of #708.