fix: type hint for get_component_by_purl is incorrect

[gruebel]

Signed-off-by: gruebel anton.gruebel@gmail.com

• adjusted the type hint for get_component_by_purl and added a test for it 🙂
• changed the list/filter expression to use a list comprehension, which is almost 2x faster in this case 🚀

[jkowalleck]

this PR needs to be discussed - see #310 (comment)

---

Thanks for the bug report, @gruebel, but to me it appears that
you bring up breaking (arch/design - not code) changes that alter the original method(API) in its meaning.

Here is a fix that does not introduce breaking changes, but actually fixes a bug

diff --git a/cyclonedx/model/bom.py b/cyclonedx/model/bom.py
--- a/cyclonedx/model/bom.py	(revision 6c0c1742d2ea19dfc0284785cf9597b43ef05979)
+++ b/cyclonedx/model/bom.py	(date 1665226315792)
@@ -300,7 +300,7 @@
             `Component` or `None`
         """
         if purl:
-            found = list(filter(lambda x: x.purl == purl, self.components))
+            found = list(filter(lambda x: str(x.purl) == purl, self.components))
             if len(found) == 1:
                 return found[0]

PS: turned out that the actual bugfix is not inteded, but a documentation fix - see #310 (comment)

[jkowalleck]

@madpah we need to triage this one.
was the typing and the method description wrong, or did we forget the string cast?

DO we have downstream users we can ask how they use this functionality right now?

How do you want to have this method implemented in the upcoming #262 ?

[gruebel]

yeap, we are using it in checkov
https://github.com/bridgecrewio/checkov/blob/2fce14ee65f4e6143c2a510e3219b9957ee5a50f/checkov/common/output/cyclonedx.py#L106-L110
and actually your suggested change would break our implementation. So, I think I did the correct thing by adjusting the type hint instead of changing the code to be aligned with the current type hint.

[jkowalleck]

yeap, we are using it in checkov https://github.com/bridgecrewio/checkov/blob/2fce14ee65f4e6143c2a510e3219b9957ee5a50f/checkov/common/output/cyclonedx.py#L106-L110 and actually your suggested change would break our implementation. So, I think I did the correct thing by adjusting the type hint instead of changing the code to be aligned with the current type hint.

In python the typing is optional and has no meaning for the runtime.
Fixing the typing and docs, while leaving the implementation untouched - this should be the least code-breaking change (downstream).

Even though I would argue that it is a breaking change from architectural/design perspective.
But in the end the usage counts for python.

[gruebel]

In python the typing is optional and has no meaning for the runtime. Fixing the typing and docs, while leaving the implementation untouched - this should be the least code-breaking change (downstream).

Even though I would argue that it is a breaking change from architectural/design perspective. But in the end the usage counts for python.

that's correct. if it was differently intended, then you should probably put it into v4 release branch 🙂

[gruebel]

hey @jkowalleck any plan on merging my change 🙂

[jkowalleck]

re: #310 (comment)
@madpah asked for a dev-stop until #262 was done. it seams like this takes longer than expected.

we will see how to get this very PR integrated.

[madpah]

I'm happy to merge this - from my checks, get_component_by_purl doesn't appear to be used internally by this library, or the cyclonedx-python app - and this is clearly a typing error.

[madpah]

Thanks @gruebel and @jkowalleck !