@@ -21,7 +21,7 @@ The current core metadata file format, version 1.2, is specified in :pep:`345`.
21
21
22
22
However, the version specifiers and environment markers sections of that PEP
23
23
have been superceded as described below. In addition, metadata files are
24
- permitted to contain the following additional field :
24
+ permitted to contain the following additional fields :
25
25
26
26
Provides-Extra (multiple use)
27
27
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -52,6 +52,70 @@ respectively.
52
52
It is legal to specify ``Provides-Extra: `` without referencing it in any
53
53
``Requires-Dist: ``.
54
54
55
+ Description-Content-Type
56
+ ~~~~~~~~~~~~~~~~~~~~~~~~
57
+
58
+ A string containing the format of the distribution's description, so that tools
59
+ can intelligently render the description. Historically, distribution
60
+ descriptions in plain text and in `reStructuredText (reST)
61
+ <http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html> `_ have
62
+ been supported and PyPI knows how to render reST into HTML. It is very common
63
+ for distribution authors to write their description in `Markdown
64
+ <https://daringfireball.net/projects/markdown/> `_ (`RFC 7763
65
+ <https://tools.ietf.org/html/rfc7763> `_). Distribution authors commonly use
66
+ Markdown probably because that's the markup language that they are most
67
+ familiar with, but PyPI historically didn't know the format of the description
68
+ and thus could not know to render a description as Markdown. This results in
69
+ PyPI having many packages where the description is rendered in a very ugly way,
70
+ because the description was written in Markdown, but PyPI is rendering it as
71
+ reST. This field allows the distribution author to specify the format of their
72
+ description and thus opens up the possibility for PyPI and other tools to be
73
+ able to render Markdown and other formats.
74
+
75
+ The format of this field is same as the ``Content-Type `` header in HTTP (e.g.:
76
+ `RFC 1341 <https://www.w3.org/Protocols/rfc1341/4_Content-Type.html >`_).
77
+ Briefly, this means that it has a ``type/subtype `` part and then it can
78
+ optionally have a number of parameters:
79
+
80
+ Format::
81
+
82
+ Description-Content-Type: <type>/<subtype>; charset=<charset>[; <param_name>=<param value> ...]
83
+
84
+ The ``type/subtype `` part has only a few legal values:
85
+
86
+ - ``text/plain ``
87
+ - ``text/x-rst ``
88
+ - ``text/markdown ``
89
+
90
+ There is one required parameter called `charset `, to specify whether the text
91
+ is UTF-8, ASCII, etc.
92
+
93
+ Other parameters might be specific to the chosen subtype. For example, for the
94
+ ``markdown `` subtype, there is a ``variant `` parameter that allows specifying
95
+ the variant of Markdown in use, such as ``Original `` for `Gruber's original
96
+ Markdown syntax <https://tools.ietf.org/html/rfc7763#section-6.1.4> `_ or
97
+ ``GFM `` for `GitHub Flavored Markdown (GFM)
98
+ <https://tools.ietf.org/html/rfc7764#section-3.2> `_.
99
+
100
+ Example::
101
+
102
+ Description-Content-Type: text/plain; charset=UTF-8
103
+
104
+ Example::
105
+
106
+ Description-Content-Type: text/x-rst; charset=UTF-8
107
+
108
+ Example::
109
+
110
+ Description-Content-Type: text/markdown; charset=UTF-8; variant=Original
111
+
112
+ Example::
113
+
114
+ Description-Content-Type: text/markdown; charset=UTF-8; variant=GFM
115
+
116
+ If a ``Description-Content-Type `` is not specified, then the assumed content type
117
+ is ``text/x-rst; charset=UTF-8 ``.
118
+
55
119
56
120
Version Specifiers
57
121
==================
0 commit comments