LICENSE.PyPDF2 missing from wheel distributions about pyhanko

[MatthiasValvekens]

Hi,

This wasn't an intentional omission, but I'd like to avoid polluting the "business" section of the wheel with data files that have no runtime relevance. Putting them in the metadata section (i.e. under pyHanko*.dist-info) would be OK as far as I'm concerned, though, as that's where all the metadata files (including pyHanko's own licence file) live. Having said that, I'm not sure if there's an easy way to hook into that using setuptools config, and whether you're even supposed to put extra stuff in there. I'll look into it; perhaps just reproducing the upstream licence in the readme is the easiest solution.

Regarding the fate of PyPDF(2): I'm well aware, and I've been in contact with the PyPDF maintainer about this before. See in particular #127 ;). Long story short, from a purely technical perspective there's nothing to update in pyHanko as such: actually very little "original" code from PyPDF2 survives in any recognisable form in pyHanko at this point.

[stefan6419846]

Thanks for your fast reply. I am completely fine with adding the second license file to the distribution info metadata directory. Some other projects like opencv-python are already doing it in a similar fashion. (I am not sure if there is a non-hacky way to include the license file usually within the package into the metadata directory, but it should work if moved to the top-level directory and added to the MANIFEST.in file.)

I would argue against putting the license into the README only though, as this tends to make license compliance for library users harder. With dedicated license files, it is easy to just use them verbatim, while within the README some further post-processing might be necessary.

[MatthiasValvekens]

I looked into this further. For now, I dealt with the issue by providing an explicit license-files directive in pyproject.toml. This way of dealing with it is not 100% standard--the method is specific to setuptools--but the result matches what opencv-python does (thanks for that pointer, by the way!).

Once PEP 639 materialises, there'll probably be a more robust way to solve this particular problem.

Thanks again for flagging this!