Generate output per target, not per package

[lfrancke]

This changes the CLI interface of the tool. It removes output-pattern and output-prefix as the name of the file is now generated from the name and type of the target.

This is because a single package can have multiple targes, some of which can be applications, one can be a library.
The old implementation would all tag the same (application if any application target exists) and the name would be the one of the package but each target can have a different name, so the resulting SBOM cannot be mapped to the artifact that is generated.

[lfrancke]

I will try to add tests for this next week

[Shnatsel]

I think this PR is a good start, but I'm not convinced that this is the final interface we want to go for.

I would prefer to make the option to write BOMs for everything opt-in, and preserve the existing flags for output selection because it may be necessary to write the BOM to a specific file in automated pipelines.

By default only one file should be written for a single target, with a sane default (binary preferred to library, failure in case multiple binaries exist) and CLI flags to control what exactly the BOM should be emitted for (--bin, --lib, --example - same as Cargo).

[lfrancke]

I'm fine with that and I'm not tied to my PR in any way. Feel free to use it in your implementation or discard all of it and start from scratch.

I'll need to think a bit about what we'd require as we'll be using this in an automated pipeline and the pipeline itself doesn't necesarily know what the target is going to be.

We're using a Docker Builder image which just builds a Rust project in a directory but only the thing using the image will then know which artifact and BOM are important.

[Shnatsel]

It occurred to me that there is more nuance to the possible requirements - for example, generating BOMs for all binaries but not the library, if a library is present along with the binaries. This will require a rather lot of flags to properly control, so I like the direction of this PR as an intermediate step towards figuring out all those flags. I would prefer for users with requirements for those flags to show up and discuss it with them, rather than try to design the flags in a vacuum.

[lfrancke]

Yeah, our use-case is definitely that we need SBOMs for all binaries but not the libraries.

[Shnatsel]

Let's get this merged and shipped, and possibly refine it later.

This clearly generates more correct SBOMs, the behavior is reasonable, and the code looks good by and large.

FYI I am not a fan of multiple unrelated changes being rolled up into a single PR (license error => debug, default behavior changed from workspace-only to all dependencies, and separate SBOMs) but I do not disagree enough with any of the changes to block this.

[Shnatsel]

Thank you for your contribution! I do believe that even if this is not the final state we want to settle on, this is a good starting point and a step in the right direction.

[Shnatsel]

This PR fixes #444, is that correct?

[lfrancke]

No..I believe that is not fixed in this PR. I couldn't figure out how to do it using the cargo API

[Shnatsel]

So there are separate SBOM files but they all include the same list of components. Is that correct?

[lfrancke]

Yes. It's still broken just in a different way :)
I only found the other issue afterwards.

Not sure if we should merge this. It'll work with top level dependencies but not "all"

I think it's strictly better than what we have today but not great.

[Shnatsel]

I see. Best hold it off until that works, then.

[lfrancke]

Agreed. I tried but didn't get it working using the current code.