Hard-coded versions in fixtures

[bollwyvl]

It appears 3.1.3 replaces the VERSION string with 3.1.2, such that when the package is tested as-installed, as we do downstream on conda-forge, some very small differences appear:

self = <tests.test_output_xml.TestOutputXml testMethod=test_bom_external_references_v1_2>

    def test_bom_external_references_v1_2(self) -> None:
>       self._validate_xml_bom(
            bom=get_bom_with_external_references(), schema_version=SchemaVersion.V1_2,
            fixture='bom_external_references.xml'
        )

src/tests/test_output_xml.py:72: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
src/tests/test_output_xml.py:568: in _validate_xml_bom
    self.assertEqualXmlBom(expected_xml.read(), output, namespace=outputter.get_target_namespace())
src/tests/base.py:172: in assertEqualXmlBom
    self.assertEqualXml(
src/tests/base.py:141: in assertEqualXml
    self.assertEqual(len(diff_results), 0, f'There are XML differences: {diff_results}\n- {a}\n+ {b}')
E   AssertionError: 1 != 0 : There are XML differences: [UpdateTextIn(node='/ns0:bom/ns0:metadata/ns0:tools/ns0:tool/ns0:version[1]', text='3.1.3')]
E   - <ns0:bom xmlns:ns0="[http://cyclonedx.org/schema/bom/1.2"](http://cyclonedx.org/schema/bom/1.2%22) version="1" serialNumber="urn:uuid:45841f2e-a458-42ef-9b7b-bbfcc39e832f"><ns0:metadata><ns0:timestamp>2023-01-07T18:38:54.962510+00:00</ns0:timestamp><ns0:tools><ns0:tool><ns0:vendor>CycloneDX</ns0:vendor><ns0:name>cyclonedx-python-lib</ns0:name><ns0:version>3.1.2</ns0:version></ns0:tool></ns0:tools></ns0:metadata><ns0:components /><ns0:externalReferences><ns0:reference type="distribution"><ns0:url>https://cyclonedx.org</ns0:url><ns0:comment>No comment</ns0:comment></ns0:reference><ns0:reference type="website"><ns0:url>https://cyclonedx.org</ns0:url></ns0:reference></ns0:externalReferences></ns0:bom>
E   + <ns0:bom xmlns:ns0="[http://cyclonedx.org/schema/bom/1.2"](http://cyclonedx.org/schema/bom/1.2%22) version="1" serialNumber="urn:uuid:45841f2e-a458-42ef-9b7b-bbfcc39e832f"><ns0:metadata><ns0:timestamp>2023-01-07T18:38:54.962510+00:00</ns0:timestamp><ns0:tools><ns0:tool><ns0:vendor>CycloneDX</ns0:vendor><ns0:name>cyclonedx-python-lib</ns0:name><ns0:version>3.1.3</ns0:version></ns0:tool></ns0:tools></ns0:metadata><ns0:components /><ns0:externalReferences><ns0:reference type="distribution"><ns0:url>https://cyclonedx.org</ns0:url><ns0:comment>No comment</ns0:comment></ns0:reference><ns0:reference type="website"><ns0:url>https://cyclonedx.org</ns0:url></ns0:reference></ns0:externalReferences></ns0:bom>

(the only difference is <ns0:version>3.1.2</ns0:version> vs <ns0:version>3.1.3</ns0:version>)

We can patch around it, but this seems like it will eventually become a problem, depending on how many places need patching...

[jkowalleck]

Thanks for the hint.

In the past, there were some attempts to use "VERSION" instead of the actual value, but they were inconsistent and caused this error you reported.

After the latest fix #335 the tests will no longer use the actual version of the library, but the constant string "TESTING".
This makes it future-prove.

Unfortunately, I cannot change the tests in the already existing version 3.1.3.
I don't think the version should be yanked, as its implementation is working as expected. Though, the tests fail.

Is there anything I can help with conda-forge?

[bollwyvl]

Thanks for the speedy reply!

I don't think the version should be yanked

Agreed! I patched the tests and (tried to) ship 3.1.3, and will just remove the patches for >=3.1.3. But: 3.1.3 is not generally available yet due to some conda-forge automation issues stemming from some large-scale token cycling required, but should be up soon, but might take a few more plumbing PRs on my part.

Is there anything I can help with conda-forge?

Thanks for the offer! Everything has been pretty smooth, thus far, aside from the occasional transient dependency issue, about which a single library can't do much about.

The one thing that would be useful for downstreams is including the test files in the sdist uploaded to pypy: at present, these are downloaded separately, but sometimes git tags move, github-generated source tarballs change their SHA, etc. Having a single distribution, with a published SHA256, would simplify things a bit, but it's not a huge lift, and worth it to have tests.

If feeling very ambitious, we're always looking for more maintainers which usually just means "update a version pin or two and click merge." But on the main, just keep doing what you're doing!

[bollwyvl]

Just to close the loop: https://anaconda.org/conda-forge/cyclonedx-python-lib/files?version=3.1.3