- All references to Pyramid-the-application were changed from :mod:`pyramid`

  to :app:`Pyramid`.  A custom role setting was added to ``docs/conf.py`` to
  allow for this.  (internal)

1 files changed, 33 insertions, 33 deletions

diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 15b9bfde5..7815106ee 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -1,13 +1,13 @@
 .. _project_narr:
 
-Creating a :mod:`pyramid` Project
+Creating a :app:`Pyramid` Project
 ====================================
 
-It's possible to create a :mod:`pyramid` application completely
+It's possible to create a :app:`Pyramid` application completely
 manually, but it's usually more convenient to use a template to
-generate a basic :mod:`pyramid` application structure.
+generate a basic :app:`Pyramid` application structure.
 
-:mod:`pyramid` comes with templates that you can use to generate a
+:app:`Pyramid` comes with templates that you can use to generate a
 project.  Each template makes different configuration assumptions
 about what type of application you're trying to construct.
 
@@ -28,10 +28,10 @@ templates".
 
 .. _additional_paster_templates:
 
-Paster Templates Included with :mod:`pyramid`
+Paster Templates Included with :app:`Pyramid`
 ------------------------------------------------
 
-The convenience ``paster`` templates included with :mod:`pyramid`
+The convenience ``paster`` templates included with :app:`Pyramid`
 differ from each other on a number of axes:
 
 - the persistence mechanism they offer (no persistence mechanism,
@@ -93,7 +93,7 @@ Creating the Project
 
 In :ref:`installing_chapter`, you created a virtual Python
 environment via the ``virtualenv`` command.  To start a
-:mod:`pyramid` :term:`project`, use the ``paster`` facility
+:app:`Pyramid` :term:`project`, use the ``paster`` facility
 installed within the virtualenv.  In :ref:`installing_chapter` we
 called the virtualenv directory ``env``; the following command
 assumes that our current working directory is that directory.
@@ -153,7 +153,7 @@ application.
 
 The ``MyProject`` project directory contains an additional subdirectory named
 ``myproject`` (note the case difference) representing a Python
-:term:`package` which holds very simple :mod:`pyramid` sample code.  This is
+:term:`package` which holds very simple :app:`Pyramid` sample code.  This is
 where you'll edit your application's Python code and templates.
 
 .. index::
@@ -241,7 +241,7 @@ The Interactive Shell
 
 Once you've installed your program for development using ``setup.py
 develop``, you can use an interactive Python shell to examine your
-:mod:`pyramid` application :term:`model` and :term:`view` objects from
+:app:`Pyramid` application :term:`model` and :term:`view` objects from
 a Python prompt.  To do so, use the ``paster`` shell command with the
 ``pshell`` argument:
 
@@ -293,7 +293,7 @@ Python interpreter shell unconditionally.
 
 You should always use a section name argument that refers to the
 actual ``app`` section within the Paste configuration file that points
-at your :mod:`pyramid` application *without any middleware wrapping*.
+at your :app:`Pyramid` application *without any middleware wrapping*.
 In particular, a section name is inappropriate as the second argument
 to ``pshell`` if the configuration section it names is a ``pipeline``
 rather than an ``app``.  For example, if you have the following
@@ -356,14 +356,14 @@ Here's sample output from a run of ``paster serve``:
    Starting server in PID 16601.
    serving on 0.0.0.0:6543 view at http://127.0.0.1:6543
 
-By default, :mod:`pyramid` applications generated from a ``paster``
+By default, :app:`Pyramid` applications generated from a ``paster``
 template will listen on TCP port 6543.
 
 During development, it's often useful to run ``paster serve`` using
 its ``--reload`` option.  When ``--reload`` is passed to ``paster
 serve``, changes to any Python module your project uses will cause the
 server to restart.  This typically makes development easier, as
-changes to Python code made within a :mod:`pyramid` application is
+changes to Python code made within a :app:`Pyramid` application is
 not put into effect until the server restarts.
 
 For example:
@@ -383,16 +383,16 @@ runtime behavior, see :ref:`environment_chapter`.
 Using an Alternate WSGI Server
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The code generated by :mod:`pyramid` ``paster`` templates assumes
+The code generated by :app:`Pyramid` ``paster`` templates assumes
 that you will be using the ``paster serve`` command to start your
 application while you do development.  However, ``paster serve`` is by
-no means the only way to start up and serve a :mod:`pyramid`
+no means the only way to start up and serve a :app:`Pyramid`
 application.  As we saw in :ref:`configuration_narr`, ``paster serve``
-needn't be invoked at all to run a :mod:`pyramid` application.  The
-use of ``paster serve`` to run a :mod:`pyramid` application is
+needn't be invoked at all to run a :app:`Pyramid` application.  The
+use of ``paster serve`` to run a :app:`Pyramid` application is
 purely conventional based on the output of its ``paster`` templates.
 
-Any :term:`WSGI` server is capable of running a :mod:`pyramid`
+Any :term:`WSGI` server is capable of running a :app:`Pyramid`
 application.  Some WSGI servers don't require the :term:`PasteDeploy`
 framework's ``paster serve`` command to do server process management
 at all.  Each :term:`WSGI` server has its own documentation about how
@@ -402,7 +402,7 @@ concepts are largely the same, whatever server you happen to use.
 
 One popular production alternative to a ``paster``-invoked server is
 :term:`mod_wsgi`. You can also use :term:`mod_wsgi` to serve your
-:mod:`pyramid` application using the Apache web server rather than
+:app:`Pyramid` application using the Apache web server rather than
 any "pure-Python" server that is started as a result of ``paster
 serve``.  See :ref:`modwsgi_tutorial` for details.  However, it is
 usually easier to *develop* an application using a ``paster serve``
@@ -427,11 +427,11 @@ This is the page shown by default when you visit an unmodified
 The Project Structure
 ---------------------
 
-Our generated :mod:`pyramid` ``pyramid_starter`` application is a setuptools
+Our generated :app:`Pyramid` ``pyramid_starter`` application is a setuptools
 :term:`project` (named ``MyProject``), which contains a Python
 :term:`package` (which is *also* named ``myproject``, but lowercased; the
 paster template generates a project which contains a package that shares its
-name except for case).  All :mod:`pyramid` ``paster`` -generated projects
+name except for case).  All :app:`Pyramid` ``paster`` -generated projects
 share a similar structure.
 
 The ``MyProject`` project we've generated has the following directory
@@ -555,7 +555,7 @@ module).  You can provide startup-time configuration parameters to
 your application by requiring more settings in this section.
 
 The ``reload_templates`` setting in the ``[app:main]`` section is a
-:mod:`pyramid` -specific setting which is passed into the
+:app:`Pyramid` -specific setting which is passed into the
 framework.  If it exists, and its value is ``true``, :term:`Chameleon`
 template changes will not require an application restart to be
 detected.  See :ref:`reload_templates_section` for more information.
@@ -565,7 +565,7 @@ detected.  See :ref:`reload_templates_section` for more information.
    turned on.
 
 The ``debug_templates`` setting in the ``[app:main]`` section is a
-:mod:`pyramid` -specific setting which is passed into the
+:app:`Pyramid` -specific setting which is passed into the
 framework.  If it exists, and its value is ``true``, :term:`Chameleon`
 template exceptions will contained more detailed and helpful
 information about the error than when this value is ``false``.  See
@@ -576,7 +576,7 @@ information about the error than when this value is ``false``.  See
    turned on.
 
 Various other settings may exist in this section having to do with
-debugging or influencing runtime behavior of a :mod:`pyramid`
+debugging or influencing runtime behavior of a :app:`Pyramid`
 application.  See :ref:`environment_chapter` for more information
 about these settings.
 
@@ -587,9 +587,9 @@ will create a new thread for each request.
 
 .. note::
 
-  In general, :mod:`pyramid` applications generated from ``paster
+  In general, :app:`Pyramid` applications generated from ``paster
   templates`` should be threading-aware.  It is not required that a
-  :mod:`pyramid` application be nonblocking as all application code
+  :app:`Pyramid` application be nonblocking as all application code
   will run in its own thread, provided by the server you're using.
 
 See the :term:`PasteDeploy` documentation for more information about
@@ -718,7 +718,7 @@ The ``myproject`` :term:`package` lives inside the ``MyProject``
    application.
 
 These are purely conventions established by the ``paster`` template:
-:mod:`pyramid` doesn't insist that you name things in any
+:app:`Pyramid` doesn't insist that you name things in any
 particular way.
 
 .. index::
@@ -741,7 +741,7 @@ also informs Python that the directory which contains it is a *package*.
 #. Line 2 imports the ``get_root`` function from
    :mod:`myproject.models` that we use later.
 
-#. Lines 4-17 define a function that returns a :mod:`pyramid`
+#. Lines 4-17 define a function that returns a :app:`Pyramid`
    WSGI application.  This function is meant to be called
    by the :term:`PasteDeploy` framework as a result of running
    ``paster serve``.
@@ -772,9 +772,9 @@ also informs Python that the directory which contains it is a *package*.
 ``views.py``
 ~~~~~~~~~~~~
 
-Much of the heavy lifting in a :mod:`pyramid` application comes in
+Much of the heavy lifting in a :app:`Pyramid` application comes in
 the form of *view callables*.  A :term:`view callable` is the main
-tool of a :mod:`pyramid` web application developer; it is a bit of
+tool of a :app:`Pyramid` web application developer; it is a bit of
 code which accepts a :term:`request` and which returns a
 :term:`response`.
 
@@ -832,13 +832,13 @@ named ``MyModel`` that provides the behavior.
 #. Line 4 defines an instance of MyModel as the root.
 
 #. Line 6 is a "root factory" function that will be called by the
-   :mod:`pyramid` *Router* for each request when it wants to find
+   :app:`Pyramid` *Router* for each request when it wants to find
    the root of the object graph.  Conventionally this is called
    ``get_root``.
 
 In a "real" application, the root object would not be such a simple
 object.  Instead, it would be an object that could access some
-persistent data store, such as a database.  :mod:`pyramid` doesn't
+persistent data store, such as a database.  :app:`Pyramid` doesn't
 make any assumption about which sort of datastore you'll want to use,
 so the sample application uses an instance of
 :class:`myproject.models.MyModel` to represent the root.
@@ -876,8 +876,8 @@ The ``tests.py`` module includes unit tests for your application.
 This sample ``tests.py`` file has a single unit test defined within
 it.  This test is executed when you run ``python setup.py test``.  You
 may add more tests here as you build your application.  You are not
-required to write tests to use :mod:`pyramid`, this file is simply
+required to write tests to use :app:`Pyramid`, this file is simply
 provided as convenience and example.
 
 See :ref:`unittesting_chapter` for more information about writing
-:mod:`pyramid` unit tests.
+:app:`Pyramid` unit tests.