Skip to content

Use pyproject.toml for PyPI README metadata - #2146

Merged
rgommers merged 2 commits into
pypa:mainfrom
harshitethic:docs-readme-pyproject-971
Nov 10, 2026
Merged

rgommers merged 2 commits into
pypa:mainfrom
harshitethic:docs-readme-pyproject-971

Conversation

@harshitethic

@harshitethic harshitethic commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

Addresses #971.

Summary

  • replace legacy setup.py README metadata guidance with [project].readme in pyproject.toml
  • show inferred Markdown/reStructuredText content types and an explicit content-type example
  • remove obsolete minimum-version guidance while retaining twine check validation

Validation

  • documentation-only change
  • isolated one-file diff

📚 Documentation preview 📚: https://python-packaging-user-guide--2146.org.readthedocs.build/en/2146/

@sinoroc sinoroc left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Seems legitimate to me

@Bilalabdulkadir

Copy link
Copy Markdown

Thanks for the update. Could you explain why using pyproject.toml is preferred in this case instead of the previous approach?

@harshitethic

Copy link
Copy Markdown
Contributor Author

Good question. The reason is standardization of the metadata declaration, not that setup.py has stopped working. PEP 621 defines the [project].readme field in pyproject.toml independently of a particular build backend; a compliant backend derives the distribution’s core Description and Description-Content-Type from it. This keeps a common README path in declarative project metadata instead of requiring project-specific Python code to read the file and populate long_description/long_description_content_type. It also lets the same guide work for projects using different modern backends. Existing projects can continue to use setup.py and its long_description options, and backends must support the relevant metadata field before a project adopts it—so I do not intend to imply that old configurations are invalid or must be migrated. The guide previously centered the legacy setuptools-specific example; my intent is to make the backend-neutral path the default for new packaging examples while keeping the core-metadata references for readers. If you would prefer an explicit legacy-configuration note in the guide as well, I can add that without suggesting a mandatory migration.

@webknjaz

Copy link
Copy Markdown
Member

https://dontquotetheai.com would be nice, though, as it's noisy.

@rgommers rgommers added component: guides type: maintenance Regular maintenance of the guide, CI and repo labels Nov 10, 2026

@rgommers rgommers left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This all looks correct and is a significant improvement to this page, so in it goes. Thanks @harshitethic and reviewers.

@rgommers
rgommers enabled auto-merge November 10, 2026 18:29
@rgommers
rgommers added this pull request to the merge queue Nov 10, 2026
Merged via the queue into pypa:main with commit 3d95d2b Nov 10, 2026
6 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

component: guides type: maintenance Regular maintenance of the guide, CI and repo

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants