| | |
| | | |
| | | .. index:: |
| | | single: cookiecutters |
| | | single: pyramid-cookiecutter-theonecc |
| | | single: pyramid-cookiecutter-starter |
| | | |
| | | .. _additional_cookiecutters: |
| | | |
| | |
| | | |
| | | - the mechanism of mapping URLs to code (:term:`URL dispatch` or :term:`traversal`) |
| | | |
| | | * `pyramid-cookiecutter-theonecc <https://github.com/Pylons/pyramid-cookiecutter-theonecc>`_ |
| | | * `pyramid-cookiecutter-starter <https://github.com/Pylons/pyramid-cookiecutter-starter>`_ |
| | | |
| | | All configuration options offer a choice of templating language. |
| | | |
| | |
| | | |
| | | .. code-block:: bash |
| | | |
| | | cookiecutter gh:Pylons/pyramid-cookiecutter-theonecc --checkout master |
| | | cookiecutter gh:Pylons/pyramid-cookiecutter-starter --checkout 1.10-branch |
| | | |
| | | If prompted for the first item, accept the default ``yes`` by hitting return. |
| | | |
| | | .. code-block:: text |
| | | |
| | | You've cloned ~/.cookiecutters/pyramid-cookiecutter-theonecc before. |
| | | You've cloned ~/.cookiecutters/pyramid-cookiecutter-starter before. |
| | | Is it okay to delete and re-clone it? [yes]: yes |
| | | project_name [Pyramid Scaffold]: myproject |
| | | repo_name [myproject]: myproject |
| | |
| | | %VENV%\Scripts\pip install -e ".[testing]" |
| | | |
| | | Once the testing requirements are installed, then you can run the tests using |
| | | the ``py.test`` command that was just installed in the ``bin`` directory of |
| | | the ``pytest`` command that was just installed in the ``bin`` directory of |
| | | your virtual environment. |
| | | |
| | | On Unix: |
| | | |
| | | .. code-block:: bash |
| | | |
| | | $VENV/bin/py.test -q |
| | | $VENV/bin/pytest -q |
| | | |
| | | On Windows: |
| | | |
| | | .. code-block:: doscon |
| | | |
| | | %VENV%\Scripts\py.test -q |
| | | %VENV%\Scripts\pytest -q |
| | | |
| | | Here's sample output from a test run on Unix: |
| | | |
| | | .. code-block:: bash |
| | | |
| | | $VENV/bin/py.test -q |
| | | $VENV/bin/pytest -q |
| | | .. |
| | | 2 passed in 0.47 seconds |
| | | |
| | | The tests themselves are found in the ``tests.py`` module in your ``cookiecutter``-generated project. Within a project generated by the ``pyramid-cookiecutter-theonecc`` cookiecutter, only two sample tests exist. |
| | | The tests themselves are found in the ``tests.py`` module in your ``cookiecutter``-generated project. Within a project generated by the ``pyramid-cookiecutter-starter`` cookiecutter, only two sample tests exist. |
| | | |
| | | .. note:: |
| | | |
| | | The ``-q`` option is passed to the ``py.test`` command to limit the output |
| | | The ``-q`` option is passed to the ``pytest`` command to limit the output |
| | | to a stream of dots. If you don't pass ``-q``, you'll see verbose test |
| | | result output (which normally isn't very useful). |
| | | |
| | | Alternatively, if you'd like to see test coverage, pass the ``--cov`` option |
| | | to ``py.test``: |
| | | to ``pytest``: |
| | | |
| | | .. code-block:: bash |
| | | |
| | | $VENV/bin/py.test --cov -q |
| | | $VENV/bin/pytest --cov -q |
| | | |
| | | Cookiecutters include configuration defaults for ``py.test`` and test coverage. |
| | | Cookiecutters include configuration defaults for ``pytest`` and test coverage. |
| | | These configuration files are ``pytest.ini`` and ``.coveragerc``, located at |
| | | the root of your package. Without these defaults, we would need to specify the |
| | | path to the module on which we want to run tests and coverage. |
| | | |
| | | .. code-block:: bash |
| | | |
| | | $VENV/bin/py.test --cov=myproject myproject/tests.py -q |
| | | $VENV/bin/pytest --cov=myproject myproject/tests.py -q |
| | | |
| | | .. seealso:: See py.test's documentation for :ref:`pytest:usage` or invoke |
| | | ``py.test -h`` to see its full set of options. |
| | | .. seealso:: See ``pytest``'s documentation for :ref:`pytest:usage` or invoke |
| | | ``pytest -h`` to see its full set of options. |
| | | |
| | | |
| | | .. index:: |
| | |
| | | .. image:: project.png |
| | | |
| | | This is the page shown by default when you visit an unmodified ``cookiecutter`` |
| | | generated ``pyramid-cookiecutter-theonecc`` application in a browser. |
| | | generated ``pyramid-cookiecutter-starter`` application in a browser. |
| | | |
| | | .. index:: |
| | | single: debug toolbar |
| | |
| | | The Project Structure |
| | | --------------------- |
| | | |
| | | The ``pyramid-cookiecutter-theonecc`` cookiecutter generated a :term:`project` (named ``myproject``), |
| | | The ``pyramid-cookiecutter-starter`` cookiecutter generated a :term:`project` (named ``myproject``), |
| | | which contains a Python :term:`package`. The package is *also* named |
| | | ``myproject``; the cookiecutter generates a project which |
| | | contains a package that shares its name. |
| | |
| | | #. ``pytest.ini`` is a configuration file for running tests. |
| | | |
| | | #. ``setup.py`` is the file you'll use to test and distribute your application. |
| | | It is a standard :term:`setuptools` ``setup.py`` file. |
| | | It is a standard :term:`Setuptools` ``setup.py`` file. |
| | | |
| | | .. index:: |
| | | single: PasteDeploy |
| | |
| | | code into a version control repository, ``setup.py sdist`` places only *Python |
| | | source files* (files ending with a ``.py`` extension) into tarballs generated |
| | | by ``python setup.py sdist``. This means, for example, if your project was not |
| | | checked into a setuptools-compatible source control system, and your project |
| | | checked into a Setuptools-compatible source control system, and your project |
| | | directory didn't contain a ``MANIFEST.in`` file that told the ``sdist`` |
| | | machinery to include ``*.pt`` files, the ``myproject/templates/mytemplate.pt`` |
| | | file would not be included in the generated tarball. |
| | |
| | | The ``MANIFEST.in`` file contains declarations which tell it to include files |
| | | like ``*.pt``, ``*.css`` and ``*.js`` in the generated tarball. If you include |
| | | files with extensions other than the files named in the project's |
| | | ``MANIFEST.in`` and you don't make use of a setuptools-compatible version |
| | | ``MANIFEST.in`` and you don't make use of a Setuptools-compatible version |
| | | control system, you'll need to edit the ``MANIFEST.in`` file and include the |
| | | statements necessary to include your new files. See |
| | | https://docs.python.org/2/distutils/sourcedist.html#principle for more |
| | | information about how to do this. |
| | | |
| | | You can also delete ``MANIFEST.in`` from your project and rely on a setuptools |
| | | You can also delete ``MANIFEST.in`` from your project and rely on a :term:`Setuptools` |
| | | feature which simply causes all files checked into a version control system to |
| | | be put into the generated tarball. To allow this to happen, check all the |
| | | files that you'd like to be distributed along with your application's Python |
| | | files into Subversion. After you do this, when you rerun ``setup.py sdist``, |
| | | all files checked into the version control system will be included in the |
| | | tarball. If you don't use Subversion, and instead use a different version |
| | | control system, you may need to install a setuptools add-on such as |
| | | control system, you may need to install a :term:`Setuptools` add-on such as |
| | | ``setuptools-git`` or ``setuptools-hg`` for this behavior to work properly. |
| | | |
| | | .. index:: |
| | |
| | | ``setup.py`` |
| | | ~~~~~~~~~~~~ |
| | | |
| | | The ``setup.py`` file is a :term:`setuptools` setup file. It is meant to be |
| | | The ``setup.py`` file is a :term:`Setuptools` setup file. It is meant to be |
| | | used to define requirements for installing dependencies for your package and |
| | | testing, as well as distributing your application. |
| | | |
| | |
| | | :language: python |
| | | :linenos: |
| | | |
| | | The ``setup.py`` file calls the setuptools ``setup`` function, which does |
| | | The ``setup.py`` file calls the :term:`Setuptools` ``setup`` function, which does |
| | | various things depending on the arguments passed to ``pip`` on the command |
| | | line. |
| | | |
| | | Within the arguments to this function call, information about your application |
| | | is kept. While it's beyond the scope of this documentation to explain |
| | | everything about setuptools setup files, we'll provide a whirlwind tour of what |
| | | everything about :term:`Setuptools` setup files, we'll provide a whirlwind tour of what |
| | | exists in this file in this section. |
| | | |
| | | Your application's name can be any string; it is specified in the ``name`` |
| | |
| | | :linenos: |
| | | |
| | | This sample ``tests.py`` file has one unit test and one functional test defined |
| | | within it. These tests are executed when you run ``py.test -q``. You may add |
| | | within it. These tests are executed when you run ``pytest -q``. You may add |
| | | more tests here as you build your application. You are not required to write |
| | | tests to use :app:`Pyramid`. This file is simply provided for convenience and |
| | | example. |