Codecov Report

Base: 66.85% // Head: 68.28% // Increases project coverage by +1.43% 🎉

Coverage data is based on head (ad44125) compared to base (7b9e8e1).
Patch coverage: 66.66% of modified lines in pull request are covered.

@@            Coverage Diff             @@
##             main     #483      +/-   ##
==========================================
+ Coverage   66.85%   68.28%   +1.43%     
==========================================
  Files          12       12              
  Lines         902      927      +25     
==========================================
+ Hits          603      633      +30     
+ Misses        299      294       -5     

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

The failing tests are due to an old version of setuptools not collecting the licenses as we expect. Maybe I need to add a fallback here.

Btw: Thanks!

Curious, I thought a) setup_requires was deprecated and b) setuptools explicitly says you can't list setuptools in setup_requires, it does nothing since setuptools is already reading it? Dropping the install_requires seems like a good move, though!

I still think the correct move here for ideal bootstrapping is to set the package up with flit. Or even have it build itself, perhaps? A custom backend isn't that hard¹ when you already have the ability to make wheels. You can hard code the contents, and then you just have to make metadata.

I still think the correct move here for ideal bootstrapping is to set the package up with flit. Or even have it build itself, perhaps? A custom backend isn't that hard1 when you already have the ability to make wheels. You can hard code the contents, and then you just have to make metadata.

I got burned before trying to switch to PEP 517 builds. I'm willing to try that again with the publicapi branch, but in the 0.x series, I'm going backwards compatibility first. Many people are running incredibly old versions of tools, as evidenced by this recent bug report.

it does nothing since setuptools is already reading it?

Not true, the version number does matter.

It seems to work fine now. I would like someone to look over the changes and give me a thumbs up if it seems a-ok.

You would have my thumbs up anyway, for fixing that; but I don't know much about Python...

looking at https://github.com/pypa/wheel/pull/483/files, from a very formal (non-semantic) perspective, changes seem to be low-invasive

except the change to license_paths from bdist_wheel adds a lot of new decision/fallback logic; I think this may cause even more maintenance issues in the future;

• the old method was simple/stupid
• the new method contains a magic number "setuptools_major_version >= 57"
• the new method contains log messages (previously none); will this be helpful/serve a purpose ?

My hunch is that license_paths from bdist_wheel is a candidate either for the next cleanup/refactoring, or for future trouble;

So I think the change to license_paths from bdist_wheel may or may not be acceptable, but may need future consideration.

the old method was simple/stupid
the new method contains a magic number "setuptools_major_version >= 57"
the new method contains log messages (previously none); will this be helpful/serve a purpose ?

The "old" method, as you saw it, was introduced in the yanked release of v0.38.0. This PR restores backwards compatibility because it can no longer guarantee a specific setuptools version.

I did some more testing and the new code breaks on setuptools older than v42, but wheel 0.37.1 works with setuptools older than that. I will fix this shortly.

Unless someone points out any glaring issues in this PR, I'll merge it tomorrow and make a new patch release.