Deprecation warnings are shown for wrong version

[stefan6419846]

I am loading the CycloneDX JSON files from projects like nh3 (distributed in the wheel): https://pypi.org/project/nh3/0.3.3/ These claim to be compliant with version 1.5 of the CycloneDX specification.

Nevertheless, loading the JSON files with this Python library throws a deprecation warning:

lib/python3.11/site-packages/cyclonedx/model/component.py:1188: DeprecationWarning: @.author is deprecated from CycloneDX v1.6 onwards. Please use @.authors or @.manufacturer instead.

This does not look correct as CycloneDX 1.6 is irrelevant for CycloneDX 1.5 files.

[jkowalleck]

the deprecation warning stems from the internal models, that tell that a certain model's property is deprecated in the latest spec.

[jkowalleck]

lets discuss possible solutions:
the internal de-serializer could, for the time of serializing, suppress any deprecation warnings.
would this be a possible solution, or do you have a different idea in mind, @stefan6419846 ?

[stefan6419846]

I think the most straightforward approach would be to not emit model-related deprecation warnings during deserialization, especially when they are about a more recent version than declared in the document. The original BOM author usually had reasons to choose this specific version and I am just the consumer. (This is of course different for serialization and/or manual creation or using old functions explicitly, which should still warn.)

Whether this is feasible without too much overhead is something I cannot evaluate, but decided to at least open a discussion about this being somehow unexpected. As a workaround, I have added a warnings filter to the corresponding BOM loading sections inside my own code.

[jkowalleck]

could you imagine opening a (draft) pull-request introducing proper tests for your cases, and maybe add a fix?

[jkowalleck]

Suppressing all the schema-related deprecation warnings could be a breaking change for some.
you never know if a downstream user caught those warnings and handled them.... so better keep this behavior.

a possible solution: dont raise DeprecationWarning but an own subclass of it.
this might then be handled like so.

import warnings

import cyclonedx.schema.deprection.SchemaDeprecationWarning

with warnings.catch_warnings(record=True) as w:
    warnings.simplefilter("always", categpry=cyclonedx.schema.deprection.SchemaDeprecationWarning)

    bom_from_xml = Bom.from_xml(...)

    for warning in w:
        ...

[stefan6419846]

I currently have a very specific workaround:

with warnings.catch_warnings():
    warnings.filterwarnings(
        action='ignore', category=DeprecationWarning, module='cyclonedx',
        message=r'^`@\.author` is deprecated from CycloneDX v1\.6 onwards\. Please use `@\.authors` or `@\.manufacturer` instead\.$'
    )
   bom = Bom.from_json()

Thus the risk of catching the wrong warning is low, although each warning I might observe would require explicitly adding it.

[jkowalleck]

Thus the risk of catching the wrong warning is low, although each warning I might observe would require explicitly adding it.

@stefan6419846 , would an explicit category help you? see #945 for the details.

[stefan6419846]

With an explicit category per version, I could avoid matching messages explicitly, which sounds like a suitable solution, yes.

[jkowalleck]

feature released via https://github.com/CycloneDX/cyclonedx-python-lib/releases/tag/v11.7.0