Description
context
Currently, components that differ only in the property bom-ref are treated as equal.
This is for the reason, that bom-ref is actually just a decorative marker for interlinkage.
Anyway, there are external tools and processes that produce CycloneDX like this:
{
"$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"metadata": {
"component": {
"type": "application",
"name": "example",
"version": "1.2.3",
"bom-ref": "topref"
}
},
"components": [
{
"type": "library",
"name": "styled-engine",
"version": "5.16.6",
"bom-ref": "@mui/styled-engine@npm:5.16.6 [296f2]"
},
{
"type": "library",
"name": "styled-engine",
"version": "5.16.6",
"bom-ref": "@mui/styled-engine@npm:5.16.6 [3135b]"
}
],
"dependencies": [
{
"ref": "topref",
"dependsOn": [
"@mui/styled-engine@npm:5.16.6 [296f2]",
"@mui/styled-engine@npm:5.16.6 [3135b]"
]
}
]
}These are, schema-wise, valid CycloneDX.
the problem
when these things are imported by this library, the components get deduplicated (since they are equal) - which causes issues with the dependency tree - and alternates the structure when exporting.
solution
bom-ref MUST be taken into account for the following processes
- equality and comparison (
__eq__,__lt__,__gt__, ...) - hashing (
__hash__)
❗ Since BomRef will become a central part of hashing and comparison, we need to revisit the respective dunder methods on BomRef.
related
closes #753