[Distutils] Alternate long_description formats, server-side

[Nick Timkovich]

I can definitely believe there are more important things to do, but some of
us aren't versed in the intricacies of what's up top and don't have the
familiarity to dive in. Us GitHub plebs are just raring to work on a
feature we think is within our grasp ;-)

On Thu, Jun 2, 2016 at 7:35 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 2 June 2016 at 15:19, Donald Stufft <donald at stufft.io> wrote:
> > On Jun 2, 2016, at 6:08 PM, Nick Timkovich <prometheus235 at gmail.com>
> wrote:
> > So yea, we need some sort of standard. It could be as simple as just
> adding
> > a field to the existing metadata specification with something like:
> >
> > Description-Format: txt|rst|md|whatever
> >
> > With the assumption that if you omit the field then we do the legacy
> > behavior of “attempt to render as rst, fallback to plain text”. You’ll
> > probably want a registry of recommended values (or perhaps, mandatory
> > values? How do we add a new type of format to the list?).
> >
> > Anyways, just an off the cuff idea, but I don’t think there’s anyone
> > seriously opposed to the idea.
>
> Yep, it's not about opposition, just a matter of there being a range
> of more important problems ahead of it in the priority queue.
>
> That said, we do now have a mechanism to document additional metadata
> fields without requiring an entire new metadata version (see
> Provides-Extra in
> https://packaging.python.org/en/latest/specifications/#core-metadata
> for an example), and there's a catalog of anticipated formats in
> https://www.python.org/dev/peps/pep-0459/#document-names, so the idea
> of defining a Description-Format field sounds plausible to me (even if
> it takes a while for tools to start emitting or reading it).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160602/0a2aff7e/attachment-0001.html>