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

Guidlines for making a PyPI-friendly readme #210

Closed
ddbeck opened this issue Jan 4, 2016 · 17 comments
Closed

Guidlines for making a PyPI-friendly readme #210

ddbeck opened this issue Jan 4, 2016 · 17 comments

Comments

@ddbeck
Copy link
Contributor

ddbeck commented Jan 4, 2016

A warehouse issue brought up the idea of documenting how to format code in READMEs for PyPI. Rather than covering code formatting alone, I thought it might be useful to have a section that covers setting the contents of a project's PyPI home page:

  • explaining where the content of a project's page on PyPI comes from (i.e., long_description)
  • setting the contents of long_description to the content of a project's README file (like the pypa sample project does)
  • using ReST to format the document and specifically calling attention to the PyPI-specific case of pygments lexers

Before I started writing, I thought I would open this issue for feedback or additional ideas.

@dstufft
Copy link
Member

dstufft commented Jan 4, 2016

Note: you can test a long_description using the exact same code that PyPI (and Warehouse) uses (modulo version numbers) using:

$ pip install readme
$ python setup.py check -r -s

@brainwane
Copy link
Contributor

@njsmith suggested it might also be good to link to https://pypi.python.org/pypi/pyroma .

@brainwane
Copy link
Contributor

I now see that https://packaging.python.org/tutorials/distributing-packages/?highlight=https#uploading-your-project-to-pypi does mention readme_renderer.

I do think a bit more explanation, mapping bits of the README to bits of a PyPI project detail page, would be useful.

@brainwane
Copy link
Contributor

brainwane commented Feb 23, 2018

The packaging and distribution tutorial currently says:

All projects should contain a readme file that covers the goal of the project. The most common format is reStructuredText with an “rst” extension, although this is not a requirement.

I think that right now we should just say it is a requirement, to simplify the experience for users, till the multiple steps laid out in pypi/warehouse#869 (comment) are completed. This would also reduce conflict with the sample project README which says that it should be written in reStructuredText.

This would reduce confusion. I was advising a person today who was trying out the new PyPI who asked,

The docs say that rst isn't the only format for readmes, but don't say what other formats are accepted. Can it handle markdown?

Until we can confidently list what other formats will render well, let's just advise people to use .rst.

@di
Copy link
Member

di commented Feb 24, 2018

I think the docs are implying that plaintext is also an option, if users don't want to use reStructuredText.

@ncoghlan
Copy link
Member

Right, the two currently fully supported formats are plain text (*.txt) and reStructuredText (*.rst). It works out that way because PyPI attempts to render with https://pypi.python.org/pypi/readme_renderer and if that fails, it treats the description as plain text.

*.md doesn't render as ReST, so it ends up being handled as plain text.

@ncoghlan
Copy link
Member

Also worth noting: PEP 566 has been accepted, so I'd expect Markdown to be supported properly over the next couple of months (pypi.python.org will still render them as plain text, but pypi.org will render them properly)

@engnadeau
Copy link

@ncoghlan do you have a branch/PR/issue we can follow for Markdown support?

@di
Copy link
Member

di commented Feb 27, 2018

@nnadeau You can follow pypi/warehouse#869, which I will close once it's possible to publish a package with a Markdown description with some subset of packaging tools.

@brainwane
Copy link
Contributor

@ddbeck If you are interested in writing "make a PyPI-friendly README" as a Guide, I for one would welcome it.

@ddbeck
Copy link
Contributor Author

ddbeck commented Mar 22, 2018

@brainwane good timing on reminding me of this! I actually have some time for this either tomorrow or Monday. Feel free to nudge me about it if there's no progress by Tuesday. :-)

@ddbeck
Copy link
Contributor Author

ddbeck commented Mar 26, 2018

OK, I didn't make as much progress on this I would've liked. I'll return to this in a couple of days. In the meantime, here's the outline I'm working from:

Title: Making a PyPI-friendly README

  • Why you would want a README and where it shows up
  • Choosing between a README.rst, README.md, or README.txt file
  • Setting long_description and long_description_content_type
  • Suggest resources for README content:
  • Testing that your README renders (with pypa/readme_renderer)

ddbeck added a commit to ddbeck/python-packaging-user-guide that referenced this issue Mar 31, 2018
@ddbeck
Copy link
Contributor Author

ddbeck commented Mar 31, 2018

OK, I've opened a PR to add a guide. I ultimately did not cover testing README rendering because the setup.py check doesn't seem to check Markdown yet. But maybe it's something we can cover later.

@brainwane
Copy link
Contributor

Per pypi/warehouse#3438 (comment) I would love for https://packaging.python.org/guides/making-a-pypi-friendly-readme/ to mention the minimum versions of these tools folks will need:

  • pkginfo>=1.4.2
  • twine>=1.11.0
  • setuptools>=38.6.0
  • wheel>=0.31.0

@di
Copy link
Member

di commented May 2, 2018

I've already made a separate issue for that: #481

Also should not that the pkginfo requirement is satisfied by upgrading twine, so we probably don't need to explicitly mention it.

@ddbeck
Copy link
Contributor Author

ddbeck commented May 18, 2018

OK, the README guide merged and the other issue is open so I'm going to close this. Thanks, everyone!

@ddbeck ddbeck closed this as completed May 18, 2018
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

6 participants