Skip to content

Conversation

@fungi
Copy link

@fungi fungi commented Jul 15, 2021

The wheel 0.32.1 release deprecated the license_file metadata option
in favor of license_files, and started raising a DeprecationWarning
exception for its use.

When installing PyYAML on platforms with no available prebuilt
wheel, such as testing with Python 3.10 beta releases, treating
warnings as errors causes versions after the addition of PR #102 to
be skipped due to this DeprecationWarning. The end result is that
PyYAML 3.13 gets installed into the environment because it's the
newest version pip is able to install without error, but that of
course doesn't actually work with modern Python interpreters.

Replace metadata.license_file with metadata.license_files in
setup.cfg to address this problem.

The wheel 0.32.1 release deprecated the license_file metadata option
in favor of license_files, and started raising a DeprecationWarning
exception for its use.

When installing PyYAML on platforms with no available prebuilt
wheel, such as testing with Python 3.10 beta releases, treating
warnings as errors causes versions after the addition of PR #102 to
be skipped due to this DeprecationWarning. The end result is that
PyYAML 3.13 gets installed into the environment because it's the
newest version pip is able to install without error, but that of
course doesn't actually work with modern Python interpreters.

Replace metadata.license_file with metadata.license_files in
setup.cfg to address this problem.
@nitzmahone
Copy link
Member

Thanks- we'll include this update in the next release, currently slated as 6.0. Meantime, I assume you already have other non-fatal DeprecationWarning exceptions in place (eg, pips import of distutils would be equally fatal), so I assume there's a decent workaround...

@fungi
Copy link
Author

fungi commented Jul 15, 2021

Thanks- we'll include this update in the next release, currently slated as 6.0. Meantime, I assume you already have other non-fatal DeprecationWarning exceptions in place (eg, pips import of distutils would be equally fatal), so I assume there's a decent workaround...

Obviously do it at whatever pace is convenient, but no it's not easy to filter this particular warning with the PYTHONWARNINGS envvar since the message contains a comma which is also treated as the delimiter (not your fault obviously, for that envvar to be truly useful Python should start escaping commas in exception messages or something). I'm not even entirely sure that envvar could be successfully plumbed all the way through to the wheel invocation pip is initiating, at least not without some changes to how pip is handling PEP 517 backends.

@nitzmahone
Copy link
Member

Ugh, yeah, I've lamented that limitation of PYTHONWARNINGS myself on many occasions :(

@fungi
Copy link
Author

fungi commented Jul 26, 2021

Oops, sorry, looks like I should create different branches for each pull request (I'm more familiar with Gerrit's workflow and find GitHub's extremely confusing).

@hugovk
Copy link
Contributor

hugovk commented Sep 22, 2021

This line can now be removed entirely, because modern wheel automatically includes any LICEN[CS]E* file. See:

https://wheel.readthedocs.io/en/stable/user_guide.html#including-license-files-in-the-generated-wheel-file

So could the entire setup.cfg file now be removed?

@nitzmahone nitzmahone mentioned this pull request Sep 23, 2021
@fungi
Copy link
Author

fungi commented Sep 23, 2021

Confirmed, I've tested and so long as wheel>=0.32.0 is used (same release which added support for the newer license_files replacement), it will include relevant license files for this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants