Make args names literal in distributing-packages

Author: rffontenelle

source/guides/distributing-packages-using-setuptools.rst

@@ -160,8 +160,8 @@ taken from the `setup.py
 
 .. _`setup() name`:
 
-name
-~~~~
+``name``
+~~~~~~~~
 
 ::
 
@@ -186,8 +186,8 @@ declare a dependency on it using any of the following spellings::
     CoOl__-.-__sTuFF
 
 
-version
-~~~~~~~
+``version``
+~~~~~~~~~~~
 
 ::
 
@@ -210,8 +210,8 @@ rather not duplicate the value, there are a few ways to manage this. See the
 
 .. _`description`:
 
-description
-~~~~~~~~~~~
+``description``
+~~~~~~~~~~~~~~~
 
 ::
 
@@ -241,8 +241,8 @@ to no formatting, `reStructuredText (reST)
 and the Github-flavored Markdown dialect of `Markdown
 <https://daringfireball.net/projects/markdown/>`_ respectively.
 
-url
-~~~
+``url``
+~~~~~~~
 
 ::
 
@@ -252,8 +252,8 @@ url
 Give a homepage URL for your project.
 
 
-author
-~~~~~~
+``author``
+~~~~~~~~~~
 
 ::
 
@@ -263,8 +263,8 @@ author
 Provide details about the author.
 
 
-license
-~~~~~~~
+``license``
+~~~~~~~~~~~
 
 ::
 
@@ -276,15 +276,15 @@ so if you want.  If you're using a standard, well-known license, then
 your main indication can and should be via the ``classifiers``
 argument. Classifiers exist for all major open-source licenses.
 
-The "license" argument is more typically used to indicate differences
+The ``license`` argument is more typically used to indicate differences
 from well-known licenses, or to include your own, unique license. As a
 general rule, it's a good idea to use a standard, well-known license,
 both to avoid confusion and because some organizations avoid software
 whose license is unapproved.
 
 
-classifiers
-~~~~~~~~~~~
+``classifiers``
+~~~~~~~~~~~~~~~
 
 ::
 
@@ -323,8 +323,8 @@ Python versions a project can be installed on, use the :ref:`python_requires`
 argument.
 
 
-keywords
-~~~~~~~~
+``keywords``
+~~~~~~~~~~~~
 
 ::
 
@@ -333,8 +333,8 @@ keywords
 List keywords that describe your project.
 
 
-project_urls
-~~~~~~~~~~~~
+``project_urls``
+~~~~~~~~~~~~~~~~
 
 ::
 
@@ -351,8 +351,8 @@ bug trackers, source repositories, or where to support package development.
 The string of the key is the exact text that will be displayed on PyPI.
 
 
-packages
-~~~~~~~~
+``packages``
+~~~~~~~~~~~~
 
 ::
 
@@ -366,8 +366,8 @@ packages.  Use the ``exclude`` keyword argument to omit packages that are not
 intended to be released and installed.
 
 
-py_modules
-~~~~~~~~~~
+``py_modules``
+~~~~~~~~~~~~~~
 
 ::
 
@@ -378,8 +378,8 @@ package, set ``py_modules`` to a list of the names of the modules (minus the
 ``.py`` extension) in order to make :ref:`setuptools` aware of them.
 
 
-install_requires
-~~~~~~~~~~~~~~~~
+``install_requires``
+~~~~~~~~~~~~~~~~~~~~
 
 ::
 
@@ -394,8 +394,8 @@ For more on using "install_requires" see :ref:`install_requires vs Requirements
 
 .. _python_requires:
 
-python_requires
-~~~~~~~~~~~~~~~
+``python_requires``
+~~~~~~~~~~~~~~~~~~~
 
 If your project only runs on certain Python versions, setting the
 ``python_requires`` argument to the appropriate :pep:`440` version specifier
@@ -427,8 +427,8 @@ And so on.
 
 .. _`Package Data`:
 
-package_data
-~~~~~~~~~~~~
+``package_data``
+~~~~~~~~~~~~~~~~
 
 ::
 
@@ -453,8 +453,8 @@ For more information, see :std:doc:`Including Data Files
 
 .. _`Data Files`:
 
-data_files
-~~~~~~~~~~
+``data_files``
+~~~~~~~~~~~~~~
 
 ::
 
@@ -487,17 +487,17 @@ For more information see the distutils section on `Installing Additional Files
   then you need to pass the ``--old-and-unmanageable`` option.
 
 
-scripts
-~~~~~~~
+``scripts``
+~~~~~~~~~~~
 
 Although ``setup()`` supports a `scripts
 <http://docs.python.org/3/distutils/setupscript.html#installing-scripts>`_
 keyword for pointing to pre-made scripts to install, the recommended approach to
 achieve cross-platform compatibility is to use :ref:`console_scripts` entry
 points (see below).
 
-entry_points
-~~~~~~~~~~~~
+``entry_points``
+~~~~~~~~~~~~~~~~
 
 ::
 
@@ -517,8 +517,8 @@ The most commonly used entry point is "console_scripts" (see below).
 
 .. _`console_scripts`:
 
-console_scripts
-***************
+``console_scripts``
+*******************
 
 ::
 
@@ -528,7 +528,7 @@ console_scripts
       ],
   },
 
-Use "console_script" `entry points
+Use ``console_script`` `entry points
 <https://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins>`_
 to register your script interfaces. You can then let the toolchain handle the
 work of turning these interfaces into actual scripts [2]_.  The scripts will be
@@ -674,8 +674,9 @@ Assuming you're in the root of your project directory, then run:
 Although somewhat cryptic, ``-e`` is short for ``--editable``, and ``.`` refers
 to the current working directory, so together, it means to install the current
 directory (i.e. your project) in editable mode.  This will also install any
-dependencies declared with "install_requires" and any scripts declared with
-"console_scripts".  Dependencies will be installed in the usual, non-editable mode.
+dependencies declared with ``install_requires`` and any scripts declared with
+``console_scripts``.  Dependencies will be installed in the usual, non-editable
+mode.
 
 It's fairly common to also want to install some of your dependencies in editable
 mode as well. For example, supposing your project requires "foo" and "bar", but