add cdx:python:package:marker property

[thomasschafer]

This PR adds a property marker to the cdx:python:package namespace, which represents the resolved marker expression for all occurrences of a dependency, as described in the specification here.

[jkowalleck]

according to python packaging,
"markers" are for dependencies - they define constraints for when a dependency shall be resolved.

Environment markers allow a dependency specification to provide a rule that describes when the dependency should be used.

CycloneDX does not allow properties in the dependency graph.
Therefore, I don't see a reason for having this property in the first place.

Anyway, the proposed property cdx:python:package:marker and it's description suggest, that a marker would have any effect on the component, or it's runtime. this is misleading and wrong.

Please discuss/explain why you think this makes sense.

[thomasschafer]

according to python packaging, "markers" are for dependencies - they define constraints for when a dependency shall be resolved.

Environment markers allow a dependency specification to provide a rule that describes when the dependency should be used.

CycloneDX does not allow properties in the dependency graph. Therefore, I don't see a reason for having this property in the first place.

Suppose we have a Python project with the following pyproject.toml:

[project]
...
dependencies = [
    "trio ; python_version >= '3.12'",
    "trio ; sys_platform == 'win32'",
]

Then we know that trio will only be required either if the Python version is at least 3.12 of if the platform is win32. We can then encode this in the component in the SBOM with the marker as follows:

          "properties": [
            {
              "name": "cdx:python:package:marker",
              "value": "python_full_version >= '3.12' or sys_platform == 'win32'"
            }
          ]

While the docs do indeed mention dependencies, we are still treating trio as a dependency of our project, and given that it is only pulled in under certain conditions it makes sense to reflect those conditions using the marker.

Specifically on this point

the proposed property cdx:python:package:marker and it's description suggest, that a marker would have any effect on the component, or it's runtime. this is misleading and wrong.

I don't follow your reasoning - if the user is on darwin and Python 3.11, then the package won't be used, so it is surely having an effect.

[madpah]

according to python packaging, "markers" are for dependencies - they define constraints for when a dependency shall be resolved.

Environment markers allow a dependency specification to provide a rule that describes when the dependency should be used.

CycloneDX does not allow properties in the dependency graph. Therefore, I don't see a reason for having this property in the first place.

Anyway, the proposed property cdx:python:package:marker and it's description suggest, that a marker would have any effect on the component, or it's runtime. this is misleading and wrong.

Please discuss/explain why you think this makes sense.

Agree with @jkowalleck.

I think this falls into the broader bucket of what you are producing an SBOM for - it should be for the shippable thing, which is perhaps a more complex thing in Python:

• From a strict perspective - it should be a Wheel (binary) distribution that targets a specific set of markers already
• The source distribution - that is harder and tbh I am unclear how this would best be represented in an SBOM as when building from source you will get a different result depending on your environment

In summary - don't think we should just add this property without wider consideration - it could lead to confusion and miss-use of CycloneDX as a BOM format IHMO.

[thomasschafer]

Thank you both for the comments - will close the PR given the discussion above