Skip to content

Conversation

@dhimmel
Copy link
Contributor

@dhimmel dhimmel commented Apr 24, 2018

Set long_description_content_type='text/markdown' in setup.py. I believe this should trigger the README to display with proper formatting on PyPI. Currently, PyPI looks like:

pypi-ecdsa

Refs https://packaging.python.org/tutorials/distributing-packages/#description and https://dustingram.com/articles/2018/03/16/markdown-descriptions-on-pypi.

@coveralls
Copy link

coveralls commented Apr 24, 2018

Coverage Status

Coverage remained the same at 85.992% when pulling f157a09 on dhimmel:patch-1 into 32e2f01 on warner:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at ?% when pulling 652fc01 on dhimmel:patch-1 into ffe9a61 on warner:master.

@dhimmel
Copy link
Contributor Author

dhimmel commented Apr 25, 2018

@di is this pull request necessary for PyPI to render the README as markdown? Note that setup.py never sets long_description. I believe PyPI is recognizing the README from

https://github.com/warner/python-ecdsa/blob/ffe9a61390c76ff6f6636e29f26b45c900535aaf/MANIFEST.in#L2

If that's the case, will PyPI automatically use markdown formatting on the next release because of the .md extension?

@di
Copy link

di commented Apr 25, 2018

If that's the case, will PyPI automatically use markdown formatting on the next release because of the .md extension?

@dhimmel No, you will need to set long_description_content_type. I would also recommend explicitly setting long_description as well, certain tools do not actually have the behavior you're describing.

(In fact, if this is happening for you now, I'd be curious what you're using to build/publish the distribution.)

Also, you're likely already aware, but you can use https://test.pypi.org/ to ensure that everything's set up correctly before actually making a new release on PyPI.

@di
Copy link

di commented Apr 25, 2018

Actually it seems like if you're using flit this might not actually be necessary, @takluyver would know for sure.

@takluyver
Copy link

Yup, with flit you point to a file for the description (like this), and it uses the extension to select the content type appropriately (.rst, .md or .txt).

@dhimmel
Copy link
Contributor Author

dhimmel commented Apr 25, 2018

Yup, with flit you point to a file for the description, and it uses the extension to select the content type appropriately (.rst, .md or .txt).

Cool. So I'm not actually involved with this repository and am not sure if flit is being used. If it is, I'll close this PR. How do you find out?

@takluyver
Copy link

It's not - if flit is in use, the repository will contain either a pyproject.toml (with the word flit in it) or flit.ini.

@dhimmel
Copy link
Contributor Author

dhimmel commented Apr 25, 2018

I would also recommend explicitly setting long_description as well, certain tools do not actually have the behavior you're describing.

Let's wait for a project maintainer. Happy to make it so setup.py sets long_description to the text of README.md in this PR if that's requested.

@tomato42
Copy link
Member

tomato42 commented Sep 4, 2018

please update it so that long_description is set and rebase on top of current master (few tools deprecated py3.3, so just updating the PR will cause Travis tests to fail)

@tomato42 tomato42 added this to the v0.14 milestone Sep 5, 2018
@dhimmel
Copy link
Contributor Author

dhimmel commented Sep 19, 2018

0118ab4 is the rebased commit. Will set long_description in next commit.

Used suggested code from
https://packaging.python.org/guides/making-a-pypi-friendly-readme/

Used io.open rather than the builtin open function to support
encoding keyword on Python 2.6 and 2.7.
@dhimmel
Copy link
Contributor Author

dhimmel commented Sep 19, 2018

please update it so that long_description is set

Done in f157a09

@tomato42 tomato42 merged commit ab23375 into tlsfuzzer:master Sep 20, 2018
@tomato42
Copy link
Member

Perfect, thank you!

@dhimmel dhimmel deleted the patch-1 branch September 20, 2018 17:44
@tomato42 tomato42 added the maintenance issues related to making the project usable or testable label Oct 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

maintenance issues related to making the project usable or testable

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants