Open mcflugen opened 2 years ago
It's up to @regebro , but it doesn't seem unreasonable at least to me to have better behavior in this circumstance, since Pyroma is producing an indeed quite confounding error (my wild guess is that your build backend injects the file anyway directly into the METADATA
, which then confuses the RFC 2822 email parser). Or perhaps (also) a more user-friendly error message raise
d from
, e.g. stating that the METADATA file could not be read due to an invalid format (which, of course, is a serious packaging problem).
Just to note, presuming my PEP 639 gets accepted, this will won't be an issue in the future since that mechanism of injecting a single license file directly into the METADATA will be deprecated and superseded by being able to specify any number of license files and have them included as files with the sdist/wheel, as setuptools
and wheel
already allow you to do.
What encoding did you use? I can't find a single encoding that has this effect.
I will get encoding errors, and they are wrapped in many errors, so trying to trap them and clarify further is probably pointless.
After upgrading to pyroma 4, I began to see the following error,
After some digging, it turns out this was caused by my license file not being UTF-8 encoded (it contained the © character).
Since PEP 621 specifies that the license file MUST be UTF-8 encoded, it makes sense that this would result in an error—just not the above error.
Would it be possible for pyroma to explicitly check for UTF-8 encoding of the license file and then to report back with a more instructive error message if that check fails?