Include my markdown README into Sphinx

If you also come across the error TypeError: add_source_parser(), here is the solution:

Using m2r2 instead of m2r. That is,

in the file readme_link.rst, we write

.. mdinclude:: ../README.md

and in the file conf.py we add

extensions = [
    # ...
    'm2r2'
]
# ...

# source_suffix = '.rst'
source_suffix = ['.rst', '.md']

I've installed myst-parser extension and tried to include a Markdown file into a .rst file

.. include:: README.md

It is not being parsed. Added :parser: markdown option, but docutils complains that "recommonmark" extension is not installed. I've found a way to include parsed md file:

.. include:: README.md
   :parser: myst_parser.sphinx_

There is an alternative approach, if you only want to include a markdown document in your project as a separate file (and don't need to embed the contents of that file into an .rst file):

1. Ensure you have the necessary prerequisites

(These steps are also requisite for the accepted answer.)

1.1 Ensure you have the markdown renderer installed:

$ pip install -U sphinx>=1.8.3 recommonmark>=0.5.0

1.2 Add recommonmark to the list of extensions in conf.py

See the documentation for canonical instructions on this.

1.3 Make a symlink to your markdown file

$ cd docs             # or docs/source
$ ln -s ../README.md  # or to ../../README.md if using docs/source

2. Include the required markdown file in your docs

Link the file in your toctree:

.. toctree::
   :maxdepth: 2
   :caption: Contents:

   source/README.md

You need to edit your readme_link.rst as follows:

Readme File
===========

.. mdinclude:: ../../README.md

Note that the section header is designated with = characters rather than - characters.

There are two factors that contribute to that.

How include works

Standard include (not mdinclude) actually reads the content of the source file and simply copies the raw text in place of the directive. M2R's mdinclude first converts the source Markdown text to rst, and then, like include, copies that test in place of the directive.

Therefore, by the time the rst document is parsed, you have one complete rst document from both the parent and included files. That one complete document needs to be a valid rst document, which takes us to the second point...

Header levels must be consistent.

As a reminder, the reStructuredText Spec explains:

Rather than imposing a fixed number and order of section title adornment styles, the order enforced will be the order as encountered. The first style encountered will be an outermost title (like HTML H1), the second style will be a subtitle, the third will be a subsubtitle, and so on.

...

All section title styles need not be used, nor need any specific section title style be used. However, a document must be consistent in its use of section titles: once a hierarchy of title styles is established, sections must use that hierarchy.

Therefore, the header levels in the included child must be consistent with the header levels in the parent. As M2R generates a rst document, you (as the end user) don't get to specificity which character is used to define each section level. Therefore, to maintain consistency, you need to use the scheme defined by M2R:

• Rst heading marks are currently hard-coded and unchangeable.
  • H1: =, H2: -, H3: ^, H4: ~, H5: ", H6: #

As you can see, level 1 headers use the = character and level 2 headers use the - character. Therefore, the same scheme needs to be used in the parent readme_link.rst file (you were using the reverse).

An alternate solution

The reStructuredText spec also states:

Underline-only adornment styles are distinct from overline-and-underline styles that use the same character.

Therefore, you could use overline-and-underline styles in your parent document and it wouldn't matter which characters you used for which level as M2R only appears to use underline-only styles. So this would have worked as well:

-----------
Readme File
-----------

.. mdinclude:: ../../README.md

This has the added benefit (or negative -- depending on your point of view) that all headers in the included child document will now be one level lower that they would on their own. Therefore, the child is more semantically "nested" in the parent (more than one h1 in a single HTML document is often considered to not be semantic although it is technically "valid"). Of course, this may or may not be what you want, which is why it is labeled an "alternate solution".