Adds fixed version for reproducible builds

[kushaldas]

Now we can rebuild the source into a wheel in any time in future, and we will still have the correct version of the project in the METADATA in wheel.

[kushaldas]

The PR has type errors due to mypy update, but nothing to do the actual PR as I understand.

[johanlundberg]

Sadly this change breaks the whole reason for this package to exist. We need monthly updates for the data that gets downloaded during the build. The actual source code for this package is of no worth without updates to the certs and metadata files.

[kushaldas]

Sadly this change breaks the whole reason for this package to exist. We need monthly updates for the data that gets downloaded during the build. The actual source code for this package is of no worth without updates to the certs and metadata files.

Does this mean every month we get a new package (source package & wheel) for this project?

Also the change I am proposing means: before one do the source build, one manually updates the version in the setup.py and then pull that month's data, and release that version, say 2023.4 and then in 2023.5. After that, when we rebuild the wheel from any of those source tarballs (even after 10 years), the result wheel file will always be the same for a given source package.

Hopefully I understood the build proper properly, I saw the Makefile target

python-fido-mds/Makefile

Line 13 in ecb3f69

update_package_data:

and assumed this way of building. Please let me know if I am wrong in this case.

[johanlundberg]

Sadly this change breaks the whole reason for this package to exist. We need monthly updates for the data that gets downloaded during the build. The actual source code for this package is of no worth without updates to the certs and metadata files.

Does this mean every month we get a new package (source package & wheel) for this project?

Correct.

Also the change I am proposing means: before one do the source build, one manually updates the version in the setup.py and then pull that month's data, and release that version, say 2023.4 and then in 2023.5. After that, when we rebuild the wheel from any of those source tarballs (even after 10 years), the result wheel file will always be the same for a given source package.

The key word here is to switch manually to automatically. Today our CI builds this package once a month, no manual intervention needed.

I am not against changing how this is done as long as it keeps getting done automatically.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud