- 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)

7 files changed, 23 insertions, 23 deletions

diff --git a/docs/tutorials/wiki2/authorization.rst b/docs/tutorials/wiki2/authorization.rst
index 1691337e9..aaf0f0184 100644
--- a/docs/tutorials/wiki2/authorization.rst
+++ b/docs/tutorials/wiki2/authorization.rst
@@ -9,7 +9,7 @@ view, edit, and add pages to our wiki.  For purposes of demonstration
 we'll change our application to allow only people whom possess a
 specific username (`editor`) to add and edit wiki pages but we'll
 continue allowing anyone with access to the server to view pages.
-:mod:`pyramid` provides facilities for *authorization* and
+:app:`Pyramid` provides facilities for *authorization* and
 *authentication*.  We'll make use of both features to provide security
 to our application.
 
@@ -29,11 +29,11 @@ Adding A Root Factory
 We're going to start to use a custom :term:`root factory` within our
 ``__init__.py`` file.  The objects generated by the root factory will be
 used as the :term:`context` of each request to our application.  In
-order for :mod:`pyramid` declarative security to work properly, the
+order for :app:`Pyramid` declarative security to work properly, the
 context object generated during a request must be decorated with
 security declarations; when we begin to use a custom root factory to
 generate our contexts, we can begin to make use of the declarative
-security features of :mod:`pyramid`.
+security features of :app:`Pyramid`.
 
 We'll modify our ``__init__.py``, passing in a :term:`root factory` to our
 :term:`Configurator` constructor.  We'll point it at a new class we create
@@ -52,7 +52,7 @@ inside our ``models.py`` file.  Add the following statements to your
            self.__dict__.update(request.matchdict)
 
 The ``RootFactory`` class we've just added will be used by
-:mod:`pyramid` to construct a ``context`` object.  The context is
+:app:`Pyramid` to construct a ``context`` object.  The context is
 attached to the request object passed to our view callables as the
 ``context`` attribute.
 
@@ -60,7 +60,7 @@ All of our context objects will possess an ``__acl__`` attribute that
 allows :data:`pyramid.security.Everyone` (a special principal) to
 view all pages, while allowing only a :term:`principal` named
 ``group:editors`` to edit and add pages.  The ``__acl__`` attribute
-attached to a context is interpreted specially by :mod:`pyramid` as
+attached to a context is interpreted specially by :app:`Pyramid` as
 an access control list during view callable execution.  See
 :ref:`assigning_acls` for more information about what an :term:`ACL`
 represents.
@@ -76,7 +76,7 @@ We'll pass the ``RootFactory`` we created in the step above in as the
 Configuring an Authorization Policy
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-For any :mod:`pyramid` application to perform authorization, we need to add a
+For any :app:`Pyramid` application to perform authorization, we need to add a
 ``security.py`` module (we'll do that shortly) and we'll need to change our
 ``__init__.py`` file to add an :term:`authentication policy` and an
 :term:`authorization policy` which uses the ``security.py`` file for a
@@ -87,7 +87,7 @@ We'll change our ``__init__.py`` file to enable an
 declarative security checking.  We'll also change ``__init__.py`` to add a
 :meth:`pyramid.configuration.Configurator.add_view` call to points at our
 ``login`` :term:`view callable`, also known as a :term:`forbidden view`.
-This configures our newly created login view to show up when :mod:`pyramid`
+This configures our newly created login view to show up when :app:`Pyramid`
 detects that a view invocation can not be authorized.  Also, we'll add
 ``view_permission`` arguments with the value ``edit`` to the ``edit_page``
 and ``add_page`` routes.  This indicates that the view callables which these
diff --git a/docs/tutorials/wiki2/background.rst b/docs/tutorials/wiki2/background.rst
index de35472bc..880b5b219 100644
--- a/docs/tutorials/wiki2/background.rst
+++ b/docs/tutorials/wiki2/background.rst
@@ -2,7 +2,7 @@
 Background
 ==========
 
-This tutorial presents a :mod:`pyramid` application that uses
+This tutorial presents a :app:`Pyramid` application that uses
 technologies which will be familiar to someone with :term:`Pylons`
 experience.  It uses :term:`SQLAlchemy` as a persistence mechanism and
 :term:`url dispatch` to map URLs to code.  It can also be followed by
@@ -12,6 +12,6 @@ To code along with this tutorial, the developer will need a UNIX
 machine with development tools (Mac OS X with XCode, any Linux or BSD
 variant, etc) *or* he will need a Windows system of any kind.
 
-This tutorial is targeted at :mod:`pyramid` version 1.0.
+This tutorial is targeted at :app:`Pyramid` version 1.0.
 
 Have fun!
diff --git a/docs/tutorials/wiki2/basiclayout.rst b/docs/tutorials/wiki2/basiclayout.rst
index 7448563c7..30e9b5b3c 100644
--- a/docs/tutorials/wiki2/basiclayout.rst
+++ b/docs/tutorials/wiki2/basiclayout.rst
@@ -4,7 +4,7 @@ Basic Layout
 
 The starter files generated by the ``pyramid_routesalchemy`` template
 are basic, but they provide a good orientation for the high-level
-patterns common to most :term:`url dispatch` -based :mod:`pyramid`
+patterns common to most :term:`url dispatch` -based :app:`Pyramid`
 projects.
 
 The source code for this tutorial stage can be browsed at
diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst
index 0826de660..83a8cf3f0 100644
--- a/docs/tutorials/wiki2/definingviews.rst
+++ b/docs/tutorials/wiki2/definingviews.rst
@@ -3,15 +3,15 @@ Defining Views
 ==============
 
 A :term:`view callable` in a :term:`url dispatch` -based
-:mod:`pyramid` application is typically a simple Python function that
+:app:`Pyramid` application is typically a simple Python function that
 accepts a single parameter named :term:`request`.  A view callable is
 assumed to return a :term:`response` object.
 
-.. note:: A :mod:`pyramid` view can also be defined as callable
+.. note:: A :app:`Pyramid` view can also be defined as callable
    which accepts *two* arguments: a :term:`context` and a
    :term:`request`.  You'll see this two-argument pattern used in
-   other :mod:`pyramid` tutorials and applications.  Either calling
-   convention will work in any :mod:`pyramid` application; the
+   other :app:`Pyramid` tutorials and applications.  Either calling
+   convention will work in any :app:`Pyramid` application; the
    calling conventions can be used interchangeably as necessary.  In
    :term:`url dispatch` based applications, however, the context
    object is rarely used in the view body itself, so within this
@@ -117,7 +117,7 @@ content of our current page object.
 We then generate an edit URL (because it's easier to do here than in
 the template), and we return a dictionary with a number of arguments.
 The fact that this view returns a dictionary (as opposed to a
-:term:`response` object) is a cue to :mod:`pyramid` that it should
+:term:`response` object) is a cue to :app:`Pyramid` that it should
 try to use a :term:`renderer` associated with the view configuration
 to render a template.  In our case, the template which will be
 rendered will be the ``templates/view.pt`` template, as per the
@@ -147,7 +147,7 @@ lazy here, so we're trying to use the same template
 (``templates/edit.pt``) for the add view as well as the page edit
 view, so we create a dummy Page object in order to satisfy the edit
 form's desire to have *some* page object exposed as ``page``, and
-:mod:`pyramid` will render the template associated with this view
+:app:`Pyramid` will render the template associated with this view
 to a response.
 
 If the view execution *is* a result of a form submission (if the
@@ -196,7 +196,7 @@ Adding Templates
 
 The views we've added all reference a :term:`template`.  Each template
 is a :term:`Chameleon` template.  The default templating system in
-:mod:`pyramid` is a variant of :term:`ZPT` provided by
+:app:`Pyramid` is a variant of :term:`ZPT` provided by
 :term:`Chameleon`.  These templates will live in the ``templates``
 directory of our tutorial package.
 
diff --git a/docs/tutorials/wiki2/distributing.rst b/docs/tutorials/wiki2/distributing.rst
index 44e0291d1..f4421e145 100644
--- a/docs/tutorials/wiki2/distributing.rst
+++ b/docs/tutorials/wiki2/distributing.rst
@@ -6,7 +6,7 @@ Once your application works properly, you can create a "tarball" from
 it by using the ``setup.py sdist`` command.  The following commands
 assume your current working directory is the ``tutorial`` package
 we've created and that the parent directory of the ``tutorial``
-package is a virtualenv representing a :mod:`pyramid` environment.
+package is a virtualenv representing a :app:`Pyramid` environment.
 
 On UNIX:
 
diff --git a/docs/tutorials/wiki2/index.rst b/docs/tutorials/wiki2/index.rst
index fd1b6e2a1..03b405048 100644
--- a/docs/tutorials/wiki2/index.rst
+++ b/docs/tutorials/wiki2/index.rst
@@ -4,7 +4,7 @@ SQLAlchemy + URL Dispatch Wiki Tutorial (For Developers Familiar with Pylons 1)
 ===============================================================================
 
 This tutorial introduces a :term:`SQLAlchemy` and :term:`url dispatch` -based
-:mod:`pyramid` application to a developer familiar with Python, and will be
+:app:`Pyramid` application to a developer familiar with Python, and will be
 most familiar to developers who have used the :term:`Pylons` 1.X web
 framework.  When the tutorial is finished, the developer will have created a
 basic Wiki application with authentication.
diff --git a/docs/tutorials/wiki2/installation.rst b/docs/tutorials/wiki2/installation.rst
index 37a99171f..e6fd5e6b9 100644
--- a/docs/tutorials/wiki2/installation.rst
+++ b/docs/tutorials/wiki2/installation.rst
@@ -56,7 +56,7 @@ Preparation, UNIX
 #. (Optional) Consider using ``source bin/activate`` to make your
    shell environment wired to use the virtualenv.
 
-#. Use ``easy_install`` to get :mod:`pyramid` and its direct
+#. Use ``easy_install`` to get :app:`Pyramid` and its direct
    dependencies installed:
 
    .. code-block:: text
@@ -107,7 +107,7 @@ Preparation, Windows
 #. (Optional) Consider using ``bin\activate.bat`` to make your shell
    environment wired to use the virtualenv.
 
-#. Use ``easy_install`` to get :mod:`pyramid` and its direct
+#. Use ``easy_install`` to get :app:`Pyramid` and its direct
    dependencies installed:
 
    .. code-block:: text
@@ -127,7 +127,7 @@ Preparation, Windows
 Making a Project
 ================
 
-Your next step is to create a project.  :mod:`pyramid` supplies a
+Your next step is to create a project.  :app:`Pyramid` supplies a
 variety of templates to generate sample projects.  We will use the
 ``pyramid_routesalchemy`` template, which generates an application
 that uses :term:`SQLAlchemy` and :term:`URL dispatch`.
@@ -277,7 +277,7 @@ the following assumptions:
 
 .. note::
 
-   :mod:`pyramid` supports any persistent storage mechanism (e.g. object
+   :app:`Pyramid` supports any persistent storage mechanism (e.g. object
    database or filesystem files, etc).  It also supports an additional
    mechanism to map URLs to code (:term:`traversal`).  However, for the
    purposes of this tutorial, we'll only be using url dispatch and