Don't load and parse spdx_license.json everytime a CollectionInfo is created.

alikins commented 5 years ago

SUMMARY

Validate CollectionInfo off static dict of spdx info.

Previously everytime a CollectionInfo() was created, the spdx_data was being loaded and parsed.

Now check it against a set of data in ansible_galaxy.data.spdx_licenses

If a license id is in the SPDX_LICENSES dict, it is acceptable. If the license items value is True, then it is deprecated and a warning is printed.

TODO: mv the deprecated license check so it only runs on 'build' and not anytime a collection is loaded

Tool to build a python source file form spdx.json

Use this to parse spdx json data when it is updated and generated a new source file.

And alternative to https://github.com/ansible/mazer/pull/170

ISSUE TYPE

Bugfix Pull Request

MAZER VERSION

name = mazer
version = 0.3.0
config_file = /home/adrian/.ansible/mazer.yml
uname = Linux, newswoop, 4.18.12-100.fc27.x86_64, #1 SMP Thu Oct 4 16:22:17 UTC 2018, x86_64
executable_location = /home/adrian/venvs/galaxy-cli-py3-2/bin/mazer
python_version = 3.6.6 (default, Jul 19 2018, 16:29:00) [GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
python_executable = /home/adrian/venvs/galaxy-cli-py3-2/bin/python

alikins commented 5 years ago

This is a little proof-of-concept at the moment.

EDIT: The stuff below has been addressed in later commits.

The building for ansible_galaxy/data/spdx_licenses.py is'nt added to the build process or tooling in this pr. And the ansible_galaxy.data.spdc_licenses.SPDX_LICENSES is a first pass. That data structure is a little weird at the moment since it is mostly a minimization of the spdx_licenses.json. The main oddity from that is the SPDC_LICENSES rhs is just a bool from the json's 'isDeprecatedLicenseId' so SPDX_LICENSES is a bit odd in that if the rhs side is True that means the license is deprecated which makes for slightly odd logic.

If the general idea makes sense, I'll revise it and make the SPDX_LICENSES rhs a dict with a key for 'deprecated' (or 'current' etc) so we could add other keys later if needed.

alikins commented 5 years ago

It may also be useful to split the current CollectionInfo model into two models. 1) one for reading galaxy.yml from installed repositories into a instance, with no validation of license 2) one used when reading galaxy.yml/MANIFEST.json from an artifact that is being publish to galaxy that would potentially enforce license info

Though I think it should be up to the server side import to decide if the license info is valid since it can and will change over time. Since it will change over time, the server side will always have to validate any way (since an old client could build an artifact using a license id that is no longer valid). If we are doing it server side on publish, we should only do it server side on publish.

ansible / mazer