[harshitethic]

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]

Seems legitimate to me

[Bilalabdulkadir]

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

[webknjaz]

This change doesn't seem to be related to the declared goal of the PR

[harshitethic]

Thanks for catching the unrelated Twine wording change. I restored the original version guidance in commit 710e30f, so the PR stays focused on modernizing README metadata examples to [project].readme. Focused local text checks and git diff --check passed; hosted documentation checks are still running.

[harshitethic]

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]

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