During packaging of python-publicsuffix2 I realized, that downloading the publicsuffix list during build time makes it unreproducible (any time the package is rebuilt, it will have a different list).
My suggestion would be to include the publicsuffix list from upstream directly as e.g. a git submodule or git subtree (the latter is preferred as this way the files actually end up in an automatically generated tarball on github when tagging a release) and not download it during build time at all to ensure reproducibility raise transparency.
The data lives in this repository already, so it could also be copied manually, but IMHO a subtree or submodule is the more transparent way of dealing with this.
Currently only the wheel on pypi.org is really ensured to carry the currently bundled version of the publicsuffix list. For anyone else building this package, this assumption is not valid.
During packaging of python-publicsuffix2 I realized, that downloading the publicsuffix list during build time makes it unreproducible (any time the package is rebuilt, it will have a different list).My suggestion would be to include the publicsuffix list from upstream directly as e.g. a git submodule or git subtree (the latter is preferred as this way the files actually end up in an automatically generated tarball on github when tagging a release) and not download it
during build timeat all toensure reproducibilityraise transparency.The data lives in this repository already, so it could also be copied manually, but IMHO a subtree or submodule is the more transparent way of dealing with this.
Currently only the wheel on pypi.org is really ensured to carry the currently bundled version of the publicsuffix list. For anyone else building this package, this assumption is not valid.