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

Added long_description_content_type #457

Merged
merged 1 commit into from
Mar 18, 2018
Merged

Conversation

9999years
Copy link

@9999years 9999years commented Mar 18, 2018

With PEP 566, the long_description can be Markdown with the long_description_content_type arg. This adds documentation for it

There were also a couple cases where filenames were enclosed with quotes rather than as code; I've changed those to be code as well for consistency.

See also:

Note that this references the README.md added in pypa/sampleproject#66, which is not yet merged. Merging that will break the link here, and merging this will result in a broken link until that PR is merged. Not sure what the best route there is.

With [PEP
566](https://www.python.org/dev/peps/pep-0566/#description-content-type-optional), the `long_description` can be Markdown with the `long_description_content_type` arg. This adds documentation for it

There were also a couple cases where filenames were enclosed with quotes
rather than as code; I've changed those to be `code` as well for
consistency.

See also:

 * [Relevant section in PEP 566](https://www.python.org/dev/peps/pep-0566/#description-content-type-optional)
 * [The CommonMark specification](http://spec.commonmark.org)
 * [The Description-Content-Type field documentation in the Python
   packaging documentation](https://packaging.python.org/specifications/core-metadata/#description-content-type-optional)
Copy link
Contributor

@brainwane brainwane left a comment

Choose a reason for hiding this comment

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

Heads-up if you'd like to be particularly fancy with your Sphinx/rST markup here: the :file: syntax might be a cool choice here for, e.g., setup.py and setup.cfg. Using :file: makes it possible for this documentation to someday format filenames in some special way. Which I think is cool. (This is in no way a "you must do this" criticism.)

@theacodes
Copy link
Member

@brainwane the :file: role is great, but the inline code role (via ``) is fine as well.

@theacodes theacodes merged commit e695953 into pypa:master Mar 18, 2018
@theacodes
Copy link
Member

Thanks, @9999years!

@9999years
Copy link
Author

Great! I’ll open another for the :file: role (I took the 10 minutes to run through the repo and change it everywhere).

@brainwane
Copy link
Contributor

Thanks for this, @9999years! Any chance we'll see you at one of our sprints this year?

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

Successfully merging this pull request may close these issues.

3 participants