Test PEP 566 features

[brainwane]

This is a checklist of stuff I'd like folks to test, to make sure our Markdown support and other PEP 566 features are super robust!

Dustin's blog post explains how to set yourself up for manual testing here. Any bugs we find in Warehouse, we'll also add an automated test to guard against in the future.

Markdown & rendering:

• see what happens when someone uses GitHub-flavored Markdown (example, GitHub help in a README. How does it look in Warehouse?
• put nonsense in the description_content_type field in setup.py
• put emoji in the README
• Unicode, special characters, etc. in the README

Provides-Extra:
The main thing I'm curious about here is whether we would provide the Provides-Extra data for a package in our package query API.

[lgh2]

I tried uploading some sample text from https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown, and not all of it rendered correctly. Tags like <h1> disappeared. Strikethroughs like ~~this~~ did not render. Tables formatted in GitHub style did not appear correctly.

As expected, Warehouse does not support GitHub-flavored Markdown.

[thebigmunch]

Fenced code blocks become <pre><code> in the CommonMark spec. See the example project for a demonstration of the strange styling that happens with that combination.

[bulletmark]

Seeing the post at https://dustingram.com/articles/2018/03/16/markdown-descriptions-on-pypi, I just tried the markdown rendering with my little project but the code blocks look much better on github sorry. Compare https://pypi.org/project/pifaceio/1.26.1 to https://github.com/bulletmark/pifaceio/tree/1.26.1.

[brainwane]

Thanks for the testing and comments! cc @di regarding especially the fenced code blocks report.

Several people have asked in other places about Warehouse supporting GitHub-flavored Markdown -- just a heads-up that I've put that into pypa/packaging-problems#126, as this is a request that spans a few different codebases.

[lgh2]

I did some testing on the long_description_content_type field, and found the following things:

• Short ASCII strings that are not valid for the field produce the following error. I managed to produce this error with the following strings: "a", "mark2343down/te43", "9384753845".

HTTPError: 400 Client Error: '9384753845' is an invalid value for Description-Content-Type. Error: 
Invalid description content type: type/subtype is not valid see 
https://packaging.python.org/specifications/core-metadata for url: https://test.pypi.org/legacy/

• Any Unicode characters that are not in the English alphabet (a single emoji, a series of emoji, emoji mixed in with ASCII characters, Arabic, Cyrillic, or a mix of English alphabet with Emoji, Arabic or Cyrillic) produced this error (500 internal server error). I was also able to produce this error by putting a 1,000 word string in the field.

Uploading distributions to https://test.pypi.org/legacy/
Uploading list_printer_package-0.3.tar.gz
100%|████████████████████████████| 7.23k/7.23k [00:00<00:00, 49.3kB/s]
Received "500: Internal Server Error" Package upload appears to have failed.  Retry 1 of 5
Uploading list_printer_package-0.3.tar.gz
100%|████████████████████████████| 7.23k/7.23k [00:00<00:00, 69.1kB/s]
Received "500: Internal Server Error" Package upload appears to have failed.  Retry 2 of 5
Uploading list_printer_package-0.3.tar.gz
100%|████████████████████████████| 7.23k/7.23k [00:00<00:00, 61.0kB/s]
Received "500: Internal Server Error" Package upload appears to have failed.  Retry 3 of 5
Uploading list_printer_package-0.3.tar.gz
100%|████████████████████████████| 7.23k/7.23k [00:00<00:00, 58.8kB/s]
Received "500: Internal Server Error" Package upload appears to have failed.  Retry 4 of 5
Uploading list_printer_package-0.3.tar.gz
100%|████████████████████████████| 7.23k/7.23k [00:00<00:00, 70.9kB/s]
Received "500: Internal Server Error" Package upload appears to have failed.  Retry 5 of 5
HTTPError: 500 Server Error: Internal Server Error for url: https://test.pypi.org/legacy/

[di]

@lgh2 Thanks for testing.

The first is expected, we strictly validate the long_description_content_type so anything outside of text/plain, text/x-rst and text/markdown should fail validation as you have seen.

I'm a little confused about the second, because I'm not seeing a corresponding exception raised from TestPyPI in Sentry. I'll have to try and reproduce.

[defjaf]

Hi,

I am (also?) seeing problems with fenced code blocks -- they are rendered with extra horizontal lines above and below each line of text within the block. See, e.g., the code block here.

[defjaf]

Plain-text web addresses are not converted to clickable links. See, e.g., the code block here (same location as my comment above, but I assume it's better separate).

[di]

I am (also?) seeing problems with fenced code blocks -- they are rendered with extra horizontal lines above and below each line of text within the block. See, e.g., the code block here.

Made a separate issue for this: #3330

Plain-text web addresses are not converted to clickable links. See, e.g., the code block here (same location as my comment above, but I assume it's better separate).

I think this is a limitation of the CommonMark variant, switching to GFM (once we ship that) should provide the behavior you're expecting.

[di]

I'm going to close this issue as I think our PEP 566 support has been adequately tested and there are other issues for problems that were found.