Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing license in sdist #379

Open
mayeut opened this issue Nov 28, 2020 · 4 comments
Open

Missing license in sdist #379

mayeut opened this issue Nov 28, 2020 · 4 comments

Comments

@mayeut
Copy link
Member

mayeut commented Nov 28, 2020

License file are automatically added when building wheel:

https://github.com/takluyver/flit/blob/8f93601d05abe00c833663df541200114dbf3ad1/flit_core/flit_core/wheel.py#L202-L204

However those files are missing in the sdist (unless using a specific include config).
Shouldn't those license files be included in the sdist automatically ?

xref pypa/packaging#357 / pypa/packaging#358

@pombredanne
Copy link

See also #525

@takluyver
Copy link
Member

As a partial workaround, a license file specified in project.license.file (new-style metadata in pyproject.toml) should always be included in an sdist. This only works for one file per project, though.

If the license files are checked in to the VCS, flit build should also always include them, although this doesn't apply if you use Flit as a backend for other tools - see #522 and #540 for more discussion about that discrepancy.

@henryiii
Copy link
Contributor

FYI, the wheel pulls the LICENSE file via a name-based search:

for base in ('COPYING', 'LICENSE'):
. It seems like the default SDist file inclusion should respect this too by including the same pattern. It means that pipx run build --wheel produces a wheel with the license file(s), but pipx run build doesn't, since it builds the wheel from the SDist, which is missing these files by default.

Specifying project.license.file isn't a great idea IMO, since it's changing if PEP 639 is accepted, it seems to indicate that Flit will treat this file as a license file (it doesn't, the wheel still uses a name-based pattern), and it only works for one file.

@jayqi
Copy link

jayqi commented Apr 10, 2024

I ran into this today and found it very surprising. The documentation from PyPA for pyproject.toml says that project.license.text should be fine, and suggests that project.license is even entirely unnecessary for a common license, so requiring project.license.file feels inconsistent here with the documented standard practices.

It's especially annoying when trying to release a package on conda-forge, which both builds conda packages from SDist and is pretty strict about requiring a LICENSE file. Now I need to do another PyPI release in order to get a valid conda-forge package.

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

No branches or pull requests

5 participants