quick_tutorial - refactor MyProject/myproject for cookiecutters

4 files changed, 23 insertions, 23 deletions

diff --git a/docs/narr/logging.rst b/docs/narr/logging.rst
index ec3590e62..87682158b 100644
--- a/docs/narr/logging.rst
+++ b/docs/narr/logging.rst
@@ -50,7 +50,7 @@ Default logging configuration is provided in both the default
 ``development.ini`` and the ``production.ini`` files.  If you use ``pyramid-cookiecutter-starter`` to generate a Pyramid project with the name of the package as ``hello_world``, then the logging configuration
 in the ``development.ini`` file is as follows:
 
-.. literalinclude:: MyProject/development.ini
+.. literalinclude:: myproject/development.ini
     :language: ini
     :lineno-match:
     :lines: 29-
@@ -253,14 +253,14 @@ translogger and your application in it.  For instance, change from this:
 .. code-block:: ini
 
     [app:main]
-    use = egg:MyProject
+    use = egg:myproject
 
 To this:
 
 .. code-block:: ini
 
     [app:mypyramidapp]
-    use = egg:MyProject
+    use = egg:myproject
 
     [filter:translogger]
     use = egg:Paste#translogger
diff --git a/docs/narr/paste.rst b/docs/narr/paste.rst
index a3f1b866e..2d4e76e24 100644
--- a/docs/narr/paste.rst
+++ b/docs/narr/paste.rst
@@ -40,25 +40,25 @@ Entry Points and PasteDeploy ``.ini`` Files
 
 In the :ref:`project_narr` chapter, we breezed over the meaning of a
 configuration line in the ``deployment.ini`` file.  This was the ``use =
-egg:MyProject`` line in the ``[app:main]`` section.  We breezed over it because
+egg:myproject`` line in the ``[app:main]`` section.  We breezed over it because
 it's pretty confusing and "too much information" for an introduction to the
 system.  We'll try to give it a bit of attention here.  Let's see the config
 file again:
 
-.. literalinclude:: MyProject/development.ini
+.. literalinclude:: myproject/development.ini
    :language: ini
    :linenos:
 
-The line in ``[app:main]`` above that says ``use = egg:MyProject`` is actually
-shorthand for a longer spelling: ``use = egg:MyProject#main``.  The ``#main``
+The line in ``[app:main]`` above that says ``use = egg:myproject`` is actually
+shorthand for a longer spelling: ``use = egg:myproject#main``.  The ``#main``
 part is omitted for brevity, as ``#main`` is a default defined by PasteDeploy.
-``egg:MyProject#main`` is a string which has meaning to PasteDeploy.  It points
+``egg:myproject#main`` is a string which has meaning to PasteDeploy.  It points
 at a :term:`setuptools` :term:`entry point` named ``main`` defined in the
-``MyProject`` project.
+``myproject`` project.
 
 Take a look at the generated ``setup.py`` file for this project.
 
-.. literalinclude:: MyProject/setup.py
+.. literalinclude:: myproject/setup.py
    :language: python
    :linenos:
 
@@ -66,18 +66,18 @@ Note that ``entry_points`` is assigned a string which looks a lot like an
 ``.ini`` file.  This string representation of an ``.ini`` file has a section
 named ``[paste.app_factory]``.  Within this section, there is a key named
 ``main`` (the entry point name) which has a value ``myproject:main``.  The
-*key* ``main`` is what our ``egg:MyProject#main`` value of the ``use`` section
+*key* ``main`` is what our ``egg:myproject#main`` value of the ``use`` section
 in our config file is pointing at, although it is actually shortened to
-``egg:MyProject`` there.  The value represents a :term:`dotted Python name`
+``egg:myproject`` there.  The value represents a :term:`dotted Python name`
 path, which refers to a callable in our ``myproject`` package's ``__init__.py``
 module.
 
-The ``egg:`` prefix in ``egg:MyProject`` indicates that this is an entry point
+The ``egg:`` prefix in ``egg:myproject`` indicates that this is an entry point
 *URI* specifier, where the "scheme" is "egg".  An "egg" is created when you run
 ``setup.py install`` or ``setup.py develop`` within your project.
 
 In English, this entry point can thus be referred to as a "PasteDeploy
-application factory in the ``MyProject`` project which has the entry point
+application factory in the ``myproject`` project which has the entry point
 named ``main`` where the entry point refers to a ``main`` function in the
 ``mypackage`` module".  Indeed, if you open up the ``__init__.py`` module
 generated within any cookiecutter-generated package, you'll see a ``main``
diff --git a/docs/narr/startup.rst b/docs/narr/startup.rst
index 1c2b7c492..cf4612602 100644
--- a/docs/narr/startup.rst
+++ b/docs/narr/startup.rst
@@ -70,7 +70,7 @@ Here's a high-level time-ordered overview of what happens when you press
    :app:`Pyramid` :term:`router` instance.  Here's the contents of an example
    ``__init__.py`` module:
 
-   .. literalinclude:: MyProject/myproject/__init__.py
+   .. literalinclude:: myproject/myproject/__init__.py
       :language: python
       :linenos:
 
@@ -86,12 +86,12 @@ Here's a high-level time-ordered overview of what happens when you press
 
    Our generated ``development.ini`` file looks like so:
 
-   .. literalinclude:: MyProject/development.ini
+   .. literalinclude:: myproject/development.ini
       :language: ini
       :linenos:
 
    In this case, the ``myproject.__init__:main`` function referred to by the
-   entry point URI ``egg:MyProject`` (see :ref:`MyProject_ini` for more
+   entry point URI ``egg:myproject`` (see :ref:`myproject_ini` for more
    information about entry point URIs, and how they relate to callables) will
    receive the key/value pairs ``{pyramid.reload_templates = true,
    pyramid.debug_authorization = false, pyramid.debug_notfound = false,
diff --git a/docs/narr/testing.rst b/docs/narr/testing.rst
index 354a462d4..406383bbd 100644
--- a/docs/narr/testing.rst
+++ b/docs/narr/testing.rst
@@ -370,11 +370,11 @@ coverage reports.
 
 Regardless of which testing :term:`package` you use, be sure to add a
 ``tests_require`` dependency on that package to your application's ``setup.py``
-file. Using the project ``MyProject`` generated by the starter scaffold as
+file. Using the project ``myproject`` generated by the starter cookiecutter as
 described in :doc:`project`, we would insert the following code immediately
-following the ``requires`` block in the file ``MyProject/setup.py``.
+following the ``requires`` block in the file ``myproject/setup.py``.
 
-.. literalinclude:: MyProject/setup.py
+.. literalinclude:: myproject/setup.py
     :language: python
     :linenos:
     :lines: 11-22
@@ -383,7 +383,7 @@ following the ``requires`` block in the file ``MyProject/setup.py``.
 
 Remember to change the dependency.
 
-.. literalinclude:: MyProject/setup.py
+.. literalinclude:: myproject/setup.py
     :language: python
     :linenos:
     :lines: 40-44
@@ -401,14 +401,14 @@ In your ``MyPackage`` project, your :term:`package` is named ``myproject``
 which contains a ``views`` module, which in turn contains a :term:`view`
 function ``my_view`` that returns an HTML body when the root URL is invoked:
 
-   .. literalinclude:: MyProject/myproject/views.py
+   .. literalinclude:: myproject/myproject/views.py
       :linenos:
       :language: python
 
 The following example functional test demonstrates invoking the above
 :term:`view`:
 
-   .. literalinclude:: MyProject/myproject/tests.py
+   .. literalinclude:: myproject/myproject/tests.py
       :linenos:
       :pyobject: FunctionalTests
       :language: python