A README file contains information about other files in a directory or archive of computer software. A form of documentation, it is usually a simple plain text file called Read Me, READ.ME, README.TXT, README.md (for a text file using markdown markup), README.1ST – or simply README. You cannot color plain text in a GitHub README.md file. You can however add color to code samples with the tags below. To do this just add tags such as these samples to your README.md file: ```json // code for coloring ``` ```html // code for coloring ``` ```js // code for coloring ``` ```css // code for coloring ``` // etc. MD to HTML Converter. CloudConvert is an online document converter. Amongst many others, we support PDF, DOCX, PPTX, XLSX. Thanks to our advanced conversion technology the quality of the output will be exactly the same as if the file was saved through the latest Microsoft Office 2019 suite.

README files can help your users understand your project and can be used to set your project’s description on PyPI.This guide helps you create a README in a PyPI-friendly format and include your README in your package so it appears on PyPI.

Creating a README file¶

README files for Python projects are often named README, README.txt, README.rst, or README.md.

For your README to display properly on PyPI, choose a markup language supported by PyPI.Formats supported by PyPI’s README renderer are:

• plain text

• reStructuredText (without Sphinx extensions)

• Markdown (GitHub Flavored Markdown by default,or CommonMark)

It’s customary to save your README file in the root of your project, in the same directory as your setup.py file.

Including your README in your package’s metadata¶

To include your README’s contents as your package description,set your project’s Description and Description-Content-Type metadata,typically in your project’s setup.py file.

For example, to set these values in a package’s setup.py file,use setup()’s long_description and long_description_content_type.

Set the value of long_description to the contents (not the path) of the README file itself.Set the long_description_content_type to an accepted Content-Type-style value for your README file’s markup,such as text/plain, text/x-rst (for reStructuredText), or text/markdown.

Note

If you’re using GitHub-flavored Markdown to write a project’s description, ensure you upgradethe following tools:

The minimum required versions of the respective tools are:

• setuptools>=38.6.0

• wheel>=0.31.0

• twine>=1.11.0

It’s recommended that you use twine to upload the project’s distribution packages:

For example, see this setup.py file,which reads the contents of README.md as long_descriptionand identifies the markup as GitHub-flavored Markdown:

Validating reStructuredText markup¶

If your README is written in reStructuredText, any invalid markup will preventit from rendering, causing PyPI to instead just show the README’s raw source.

Note that Sphinx extensions used in docstrings, such asdirectives and roles(e.g., “:py:func:`getattr`” or “:ref:`my-reference-label`”), are not allowed here and will result in errormessages like “Error:Unknowninterpretedtextrole'py:func'.”.

You can check your README for markup errors before uploading as follows:

1. Install the latest version of twine;version 1.12.0 or higher is required:

   Unix/macOSWindows

2. Build the sdist and wheel for your project as described underPackaging your project.

3. Run twinecheck on the sdist and wheel:

   This command will report any problems rendering your README. If your markuprenders fine, the command will output CheckingdistributionFILENAME:Passed.

A READMEfile contains information about other files in a directory or archive of computer software. A form of documentation, it is usually a simple plain text file called Read Me, READ.ME,^[1]README.TXT,^[2][1]README.md^[1] (for a text file using markdown markup), README.1ST^[1] – or simply README.^[1]

The file's name is generally written in uppercase letters. On Unix-like systems in particular this makes it easily noticed – both because lowercase filenames are more common, and because traditionally the ls command sorts and displays files in ASCII-code order, so that uppercase filenames appear first.^{[nb 1]}

Contents[edit]

The contents typically include one or more of the following:

• Configuration instructions
• Installation instructions
• Operating instructions
• A file manifest (list of files included)
• Copyright and licensing information
• Contact information for the distributor or programmer
• Known bugs^[3]
• Troubleshooting^[3]
• Credits and acknowledgments
• A changelog (usually for programmers)
• A news section (usually for users)

History[edit]

It is unclear when the convention began, but there are examples dating back to the mid 1970s.^{[4][5][6][7][8][9][1][better source needed]} Early Macintosh system software installed a Read Me on the startup disk, and they commonly accompanied third-party software.

In particular, there is a long history of free software and open-source software including a README file; the GNU Coding Standards.^[10] encourage including one to provide 'a general overview of the package'.

Since the advent of the web as a de facto standard platform for software distribution, many software packages have moved (or occasionally, copied) some of the above ancillary files and pieces of information to a website or wiki, sometimes including the README itself, or sometimes leaving behind only a brief README file without all of the information required by a new user of the software.

In more recent times, the popular GitHub proprietary Git repository^[11] strongly encourages a README file - if one is included in the main (top-level) directory, it is automatically presented on the main web page. While traditional plain text is supported, various different file extensions and formats are also supported,^[12] and conversion to HTML takes account of the file extension of the file – in particular a 'README.md' file would be treated as a GitHub Flavored Markdown file.

As a generic term[edit]

The expression 'readme file' is also sometimes used generically, for files with a similar purpose.^{[citation needed]} For example, the source code distributions of many free software packages, especially those following the Gnits Standards or those produced with GNU Autotools, include a standard set of readme files:

Github Code In Readme Markup Example

Other files commonly distributed with software include a FAQ and a TODO file listing possible future changes.

See also[edit]

Notes[edit]

1. ^This is often no longer the case – but LC_ALL=C ls will show the older behavior.

Gitlab Readme Markup

References[edit]

1. ^ ^abcdefAbdelhafith, Omar (2015-08-13). 'README.md: History and Components'. Archived from the original on 2020-01-25. Retrieved 2020-01-25.
2. ^Raymond, Eric Steven (1996). The New Hacker's Dictionary. MIT Press. pp. 378–79. ISBN978-0-26268092-9. Hacker's-eye introduction traditionally included in the top-level directory of a Unix source distribution, containing a pointer to more detailed documentation, credits, miscellaneous revision history, notes, etc. […] When asked, hackers invariably relate the README convention to the famous scene in Lewis Carroll's Alice's Adventures In Wonderland in which Alice confronts magic munchies labeled 'Eat Me' and 'Drink Me'.
3. ^ ^abManes, Stephen (November 1996). 'README? Sure--before I buy!'. PC World. 14 (11): 366.
4. ^'PDP-10 Archive: decus/20-0079/readme.txt from decus_20tap3_198111'. pdp-10.trailing-edge.com. 1974-11-27. Retrieved 2018-03-03. [README.TXT is the DOC file for SPICE/SINC/SLIC] This failsafe tape contains the circuit analysis programs SPICE SINC and SLIC described in the Applications Software Bulletin Volume 4. requirements: SPICE requires FORTRAN-10 version 4 because of its use of Right adjusted Holerith data. Executes in about 47K. […] it also includes this file, the FOROTS to go with the SAVes and the source for SECOND.MAC, the timing routine. SPICE is broken into three parts: 1SPICE.FOR, 2 and 3. There is a printed document to describe each of the programs. These are included in the DECUS packet. The documentation and programs were originally developed by the E.E. department of the Univ. of Calif. at Berkeley on a CDC 6400. Except to convert the FORTRAN to the DECsystem-10 no changes have been made to the programs. For the test data SLIC and SINC have shown a slight variation with respect to the 6400, SPICE shows no variation. Good luck! Ashley Grayson 27-NOV-74 [end of README.TXT]
5. ^'DECUS 10-LIB-4 Contains 10-210 through 10-241, except 10-223'. pdp-10.trailing-edge.com. 1975-03-27. Retrieved 2018-03-03. The files on this FAILSAFE tape constitute the UCI LISP system. They are for the most part documented in the UCI LISP Manual, available from the Department of Information and Computer Science at the University of California, Irvine, California.[1]
6. ^'Programmer's Workbench /sys/source/lex/README'. July 1977. Retrieved 2020-01-25.
7. ^'Unix 7th edition /usr/doc/README'. 1979. Retrieved 2020-01-25.
8. ^'First 32bit BSD usr/doc/README'. March 1980. Retrieved 2020-01-25.
9. ^Langemeier, Jeff (2011-07-29). 'Re: Origin of README'. Retrieved 2020-01-25 – via Stackexchange. […] they had READMEs (actual physical printed files) for all of their punch cards and mag tape and pretty much anything else that was a 'program'. At that time you really needed one because of the labourous process that was involved with getting the created, ran, and everything else. These READMEs sometimes also included the actual printouts of how the punch cards were supposed to be punched as a form of error checking and debugging. The convention apparently also follows the old system in that with all the punch cards a 'reem' of paper was attached with the statement README in caps printed on it, this had all of the instructions for use and loading of the punch cards into the system. For a time reference, this would have been in the 60s. […]
10. ^'GNU Coding Standards: Releases'. www.gnu.org. Retrieved 2018-03-03.
11. ^'Code-sharing site Github turns five and hits 3.5 million users, 6 million repositories'. TheNextWeb.com. 2013-04-11. Retrieved 2013-04-11.
12. ^'Markup'. GitHub. GitHub. 2014-12-25. Retrieved 2015-02-08.

Readme Markup Bold

Further reading[edit]

Readme Markup Editor

• Johnson, Mark (1997-02-01). 'Building a Better ReadMe'. Technical Communication. Society for Technical Communication. 44 (1): 28–36. JSTOR43089849.[2][3]
• Rescigno, Jeanne (August 1997). 'Hypertext good choice for README files'. Technical Communication. Society for Technical Communication. 44 (3): 214. JSTOR43089876.
• Livingston, Brian (1998-09-14). 'Check your Readme files to avoid common Windows problems'. InfoWorld. Vol. 20 no. 37. InfoWorld Media Group, Inc. p. 34. Archived from the original on 2006-11-18. Retrieved 2019-06-04.[4]
• Benjamin, Andrew (1996-09-15) [1993]. Written at Department of Philosophy, University of Warwick, UK. Guédon, Jean-Claude (ed.). 'Readme: Writing Notes - Meditations on the temporality of writing'. Surfaces (Electronic journal) (in English and French). Université de Montréal, Montreal (Quebec), Canada: Les Presses de l'Université de Montréal. III (12): 1–12. ISSN1188-2492. Archived from the original on 2006-02-20. Retrieved 2019-06-04.[5]

Readme Markup Cheat Sheet

This article is based in part on the Jargon File, which is in the public domain.

Readme Markup