[FEAT] Define hierarchical and flat merge methods

The C# Library and the CLI tool expose to the user the methods for merging different SBOMs using either hierarchical or flat strategies. This is completely absent in the python library and forces to user to write them leading to differences in implementations. Would it make sense to expose this function/method? The C# library HierarchicalMerge function takes in a list of boms and the merge component, so i guess it would be something like

def hierachical_merge(boms, metadata_component):
    # merge stuff
    return merged_bom

while the flat merge

def flat_merge(boms):
    return merged_bom

Reference to C# https://github.com/CycloneDX/cyclonedx-dotnet-library/blob/b5fbaf66e4fcae632950744f66b7f37e41e2dcb3/src/CycloneDX.Utils/Merge.cs#L125

The implementation for the flat merge on the other hand is really simple

        public static Bom FlatMerge(IEnumerable<Bom> boms)
        {
            var result = new Bom();

            foreach (var bom in boms)
            {
                result = FlatMerge(result, bom);
            }

            return result;
        }

Currently, there is no common ground for such a feature in the library.
This might change in the future, feel free to discuss.

Some trivia:

[...] methods for merging different SBOMs using either hierarchical or flat strategies.
This is completely absent in the python library and forces to user to write them leading to differences in implementations. Would it make sense to expose this function/method?

The merge topic is disputable and no consensus was found - see CycloneDX/specification#320.
Every user has different requirements to the merge result, and an authoritative guide to merging does not exist.

This is completely absent in the python library [...]

This is for the following reasons

there is a working implementation already: the CyclonedX CLI tool - not an API, but a stable CLI that can be used programmatically for merging things.
merging is disputable - as stated above
this library enables everybody to implement the merge algorithm as they need it - it is either trivial (-> no need to have this snipped as part of the library) or complex and "different" (-> no common implementation -> no way to have this snipped as part of the library)

You are right for the most part, but isnt using the CLI tool just a more complex way to use the .Net library?
This forces you to either:

implement it yourself (which, as i understood, you think its a good way to go about it)
use the cli (relying on C# libraries)

It doesnt make sense for a developer using the python library having to resort to C# stuff or cli binaries, expecially when despite no consensus on the implementation it is indeed implemented inside the official tool, implementing the 2 algorithms inside the library doesnt take away the choice of making your own, it just exposes an implementation of the ones used by the official cli tool.

Instead of just doing python bom objects -> merged_objects this forces devs to do python bom objects -> produce sbom json/xml -> cli tool merge -> python load merged bom -> python merged bom object.

This creates WAY more possibile points of failure imho

i have written the merge function myself, if its welcomed i can make a pr.

i have written the merge function myself, if its welcomed i can make a pr.

why not have it as a "contrib" extension.

please pull-request your implementation(s) to a path like /cyclonedx/contrib/<my_functionality>.py

PS: see the ongoing prep in #916

since #916
was merged, the proper place for these merge methods could be one of these:

cyclonedx/contrib/merge
cyclonedx/contrib/bom/merge

I'll probably pr this with my work email, i implemented the hierarchical merge, do you think the flat version would be useful as well? I honestly cant find a good reason to use it

I'll probably pr this with my work email, i implemented the hierarchical merge, do you think the flat version would be useful as well? I honestly cant find a good reason to use it

Just do how you feel.
With that new contrib area being wild, everything is possible.

Navigation Menu

Repository navigation

[FEAT] Define hierarchical and flat merge methods #909

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEAT] Define hierarchical and flat merge methods #909

Description

Activity

woshiwuja commented on Nov 12, 2025

woshiwuja commented on Nov 12, 2025

jkowalleck commented on Nov 12, 2025

woshiwuja commented on Nov 12, 2025

woshiwuja commented on Nov 25, 2025

jkowalleck commented on Nov 25, 2025

jkowalleck commented on Dec 2, 2025

woshiwuja commented on Dec 10, 2025

jkowalleck commented on Dec 10, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions