Skip to content

pyproject.toml: PEP 639 compatibility #209

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.

Sign up for GitHub

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

Open
adamjstewart wants to merge 3 commits into
base: main
Choose a base branch
from
Open

pyproject.toml: PEP 639 compatibility #209

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
264c1fb
pyproject.toml: PEP 639 compatibility
adamjstewart Oct 30, 2025
de36519
setuptools 77.0.3+
adamjstewart Nov 22, 2025
d4ca023
MIT-0 AND MIT
adamjstewart Nov 22, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,7 @@
[build-system]
requires = [
# first version that supports Python 3.12; older versions may work
# with previous Python versions, but are not tested
"setuptools >= 66.1"
# Required for PEP 639 support
"setuptools >= 77.0.3"
]
build-backend = "setuptools.build_meta"

Expand All @@ -16,7 +15,8 @@ requires-python = ">=3.9"

description = "Foreign Function Interface for Python calling C code."
readme = "README.md"
license = { file = "LICENSE" }
license = "MIT-0 AND MIT"
license-files = ["LICENSE", "src/c/libffi_x86_x64/LICENSE"]
Copy link
Contributor

@mattip mattip Dec 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This adds the license for libffi_x86_64. Is this part of the wheel for all platform or just x86_64?

Copy link
Author

@adamjstewart adamjstewart Dec 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment, license-files cannot be configured dynamically, it must be the same for all platforms: https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html#dynamic-metadata. Whether or not the license for libffi should be included or excluded is another question.

Copy link
Author

@adamjstewart adamjstewart Dec 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are also from-source builds that will not bundle libffi at all.

Copy link
Contributor

@DimitriPapadopoulos DimitriPapadopoulos Dec 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's distributed with the source dist, isn't it? I would therefore argue the package should reference that licence.

Copy link
Contributor

@DimitriPapadopoulos DimitriPapadopoulos Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since I wrote that, I've learned the exact scope of license has been discussed elsewhere. From pypa/pip#13747 (comment):

Whether to include the vendored licenses in the license field was discussed in the PR that added it: pypa/pip#13335

Which led to an extensive discussion on DPO about the intent and wording of the PEP: https://discuss.python.org/t/expressing-project-vs-distribution-licenses-post-pep-639/90314. That discussion become too onerous for me to follow, but I believe the conclusion was the license is for the project and there may be future PEPs to cover the distribution licenses? But I could be wrong about that.

See also pypa/pip#13747 (comment).

classifiers = [
"Programming Language :: Python",
"Programming Language :: Python :: 3",
Expand Down
Loading