get_components_without_* functions shold return the SPDX ID of the component if there is one
CsatariGergely opened this issue · comments
get_components_without_* functions return with the list of component names (except get_components_without_names()), but I think they should return with the SPDX ID (if there is one). With the SPDX id it is possible to get the SPDX element with the spdx_tools package, while with the name this is not possible.
Maybe the functions could return with a tuple of the name and the SPDX ID.
Bonus bug: get_components_without_versions()'s description claims that it returns with the SPDX ID (https://github.com/spdx/ntia-conformance-checker/blob/main/ntia_conformance_checker/sbom_checker.py#L78)
@CsatariGergely, thank you for the bug report. I didn't know this: "With the SPDX id it is possible to get the SPDX element with the spdx_tools package, while with the name this is not possible." Given that, I especially support this fix.
I personally like the tuple idea!
This would be a breaking change, so I propose collecting some feedback before ntia-conformance-checker implements this change. @goneall: thoughts? Anyone you would like to collect feedback from?
And nice job on the bonus bug.
Anybody reading this, PRs welcome!
I would be concerned about breaking changes in the API - we're not sure how many people are using these.
One thought is to create separate functions under a different name or add an optional parameter to maintain compatibility.
I would be concerned about breaking changes in the API - we're not sure how many people are using these.
One thought is to create separate functions under a different name or add an optional parameter to maintain compatibility.
yes, maybe an optional parameter is a good idea. I can craft a pr for this.
I like the optional parameter approach. I'll review the associated PR this weekend. Thank you, @CsatariGergely!
@CsatariGergely, again, thank you. I keep thinking that ntia-conformance-checker is feature-complete, and I keep finding out it is not thanks to issues and PRs like yours.
I have a few questions.
First, is this feature something you, a project you work on, or a product you work is going to benefit from? I assume it is. In that case, I'm glad to eventually merge this PR, or a slightly amended version. I want to make sure because I don't want to add complexity to this codebase unless I know you, a project, or a product is going to benefit from the feature that creates this added complexity.
Second, is there a reason you prefer to return a tuple of both the SPDX ID and the name? What do you think about either returning a list of SPDX IDs or a list of component names? To me, thinking about it, it doesn't seem obvious to have one option that returns a list of component names and one options that returns a tuple. It seems more logical to have one option that returns SPDX IDs and one option that returns component names. What do you think?
Third, do you prefer to keep this returnTuples flag (or whatever we eventually call that flag) only accessible via the method functions? Or would you prefer that this option be set when invoking the SbomChecker class? It's a question of what functionality would benefit you and future users.
Again, thank you! And happy holidays!
We are building our internal SBOM compliance checker and checking for the NTIA minimum element is part of the compliance. Our compliance checker prints all compliance violations in a table with the SPDX ID and the Name of the element. From the Name spdx-tools does not provide a function to get the SPDX ID (it does provide a function to get the element from the SPDX ID though (however it is not relevant if I can get back both from ntia-conformance-checker)).
For my use case the most simple solution would be to return with both the SPDX ID and the Name. I can live with an option to return with the SPDX ID only (so I can use the aforementioned function in spdx-tools to get the name).
I think having an option via method functions is more flexible than a general option set at construction time.
Thanks for the helpful answers to my questions, @CsatariGergely!
We'll keep the tuples then!
I think having an option via method functions is more flexible than a general option set at construction time.
Sounds good.
Again, thank you for the issue and PR. After the PR gets a review from @goneall too, then we can merge it and I'll cut a new release.
@CsatariGergely: thank you. The PR is merged and I cut a new release. Keep the issues coming. And PRs always welcome.
Great, thanks.