-
Notifications
You must be signed in to change notification settings - Fork 41
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
Add a note about long_description_content_type='text/markdown' #25
Comments
The cookiecutter's README is an rst file. I judged it was easier to only discuss that one markup syntax, since rst is used in sphinx anyway. Do you think we should change it to Markdown? |
No, I'm perfectly fine with the |
I think this starts to head us toward to many options. The beauty of this tutorial is that it keeps things very simple, I am not sure we want to confuse entry level people by giving them a bunch of 'options'. We could state from the start that in every step there are options but we have chosen to concentrate one one option in each case for simplicity. |
@awalter-bnl, that's a fair point, though this kind of knowledge it usually struggled to obtain, so sharing may save people some time. |
This is a fair point, I suppose the underlying question is who is this aimed at: Entry level scientists, where giving 'options' will confuse them, or mid-level scientists/programmers who want to find out what the options are. Personally I think this works really well for entry level scientists as it is currently written, but I leave the question regarding who it should be aimed at up to others. |
^ This is my thought too. I picture someone reading this and wondering, "So wait, do I have to know this? Why would I choose Markdown vs rst? Can I do my sphinx docs in Markdown too?" --- all natural questions that we would probably also have to address. But I hear your point @mrakitin. The bummer is that this information is hard to discover, especially because this is a pretty new feature of setuptools. Maybe we could stuff notes like this into something like an FAQ? Let's leave this issue open and circle back in a couple months to see if there is a natural place to stick tid-bits like this, in some sort of appendix or something. I'm sure we don't want to include on "the main path". |
More info here: https://packaging.python.org/guides/making-a-pypi-friendly-readme/. |
It's possible to automatically render
README.md
markdown documents on PyPI. For that, an extra setup parameter is needed (example):I think it's worth to mention it in the documentation.
The text was updated successfully, but these errors were encountered: