Merge remote-tracking branch 'upstream/master' into merge-master-into-features

doc/en/contents.rst

@@ -3,7 +3,7 @@
 Full pytest documentation
 ===========================
 
-`Download latest version as PDF <pytest.pdf>`_
+`Download latest version as PDF <https://media.readthedocs.org/pdf/pytest/latest/pytest.pdf>`_
 
 .. `Download latest version as EPUB <http://media.readthedocs.org/epub/pytest/latest/pytest.epub>`_
 

doc/en/customize.rst

@@ -29,25 +29,29 @@ project/testrun-specific information.
 
 Here is the algorithm which finds the rootdir from ``args``:
 
-- determine the common ancestor directory for the specified ``args``.
+- determine the common ancestor directory for the specified ``args`` that are
+  recognised as paths that exist in the file system. If no such paths are
+  found, the common ancestor directory is set to the current working directory.
 
-- look for ``pytest.ini``, ``tox.ini`` and ``setup.cfg`` files in the
-  ancestor directory and upwards.  If one is matched, it becomes the
-  ini-file and its directory becomes the rootdir.  An existing
-  ``pytest.ini`` file will always be considered a match whereas
-  ``tox.ini`` and ``setup.cfg`` will only match if they contain
-  a ``[pytest]`` section.
+- look for ``pytest.ini``, ``tox.ini`` and ``setup.cfg`` files in the ancestor
+  directory and upwards.  If one is matched, it becomes the ini-file and its
+  directory becomes the rootdir.
 
-- if no ini-file was found, look for ``setup.py`` upwards from
-  the common ancestor directory to determine the ``rootdir``.
+- if no ini-file was found, look for ``setup.py`` upwards from the common
+  ancestor directory to determine the ``rootdir``.
 
-- if no ini-file and no ``setup.py`` was found, use the already
-  determined common ancestor as root directory.  This allows to
-  work with pytest in structures that are not part of a package
-  and don't have any particular ini-file configuration.
+- if no ``setup.py`` was found, look for ``pytest.ini``, ``tox.ini`` and
+  ``setup.cfg`` in each of the specified ``args`` and upwards. If one is
+  matched, it becomes the ini-file and its directory becomes the rootdir.
 
-Note that options from multiple ini-files candidates are never merged,
-the first one wins (``pytest.ini`` always wins even if it does not
+- if no ini-file was found, use the already determined common ancestor as root
+  directory. This allows to work with pytest in structures that are not part of
+  a package and don't have any particular ini-file configuration.
+
+Note that an existing ``pytest.ini`` file will always be considered a match,
+whereas ``tox.ini`` and ``setup.cfg`` will only match if they contain a
+``[pytest]`` section. Options from multiple ini-files candidates are never
+merged - the first one wins (``pytest.ini`` always wins, even if it does not
 contain a ``[pytest]`` section).
 
 The ``config`` object will subsequently carry these attributes:

doc/en/example/simple.rst

@@ -720,40 +720,29 @@ and run it::
 You'll see that the fixture finalizers could use the precise reporting
 information.
 
-Integrating pytest runner and cx_freeze
------------------------------------------------------------
+Freezing pytest 
+---------------
 
 If you freeze your application using a tool like
-`cx_freeze <https://cx-freeze.readthedocs.io>`_ in order to distribute it
-to your end-users, it is a good idea to also package your test runner and run
-your tests using the frozen application.
+`PyInstaller <https://pyinstaller.readthedocs.io>`_
+in order to distribute it to your end-users, it is a good idea to also package
+your test runner and run your tests using the frozen application. This way packaging
+errors such as dependencies not being included into the executable can be detected early
+while also allowing you to send test files to users so they can run them in their
+machines, which can be useful to obtain more information about a hard to reproduce bug.
 
-This way packaging errors such as dependencies not being
-included into the executable can be detected early while also allowing you to
-send test files to users so they can run them in their machines, which can be
-invaluable to obtain more information about a hard to reproduce bug.
+Fortunately recent ``PyInstaller`` releases already have a custom hook
+for pytest, but if you are using another tool to freeze executables 
+such as ``cx_freeze`` or ``py2exe``, you can use ``pytest.freeze_includes()``
+to obtain the full list of internal pytest modules. How to configure the tools
+to find the internal modules varies from tool to tool, however.
 
-Unfortunately ``cx_freeze`` can't discover them
-automatically because of ``pytest``'s use of dynamic module loading, so you
-must declare them explicitly by using ``pytest.freeze_includes()``::
+Instead of freezing the pytest runner as a separate executable, you can make 
+your frozen program work as the pytest runner by some clever
+argument handling during program startup. This allows you to 
+have a single executable, which is usually more convenient.
 
-    # contents of setup.py
-    from cx_Freeze import setup, Executable
-    import pytest
-
-    setup(
-        name="app_main",
-        executables=[Executable("app_main.py")],
-        options={"build_exe":
-            {
-            'includes': pytest.freeze_includes()}
-            },
-        # ... other options
-    )
-
-If you don't want to ship a different executable just in order to run your tests,
-you can make your program check for a certain flag and pass control
-over to ``pytest`` instead. For example::
+.. code-block:: python
 
     # contents of app_main.py
     import sys
@@ -766,7 +755,8 @@ over to ``pytest`` instead. For example::
         # by your argument-parsing library of choice as usual
         ...
 
-This makes it convenient to execute your tests from within your frozen
-application, using standard ``pytest`` command-line options::
+
+This allows you to execute tests using the frozen
+application with standard ``pytest`` command-line options::
 
     ./app_main --pytest --verbose --tb=long --junitxml=results.xml test-suite/

doc/en/getting-started.rst

@@ -11,7 +11,7 @@ Installation and Getting Started
 `colorama (Windows) <http://pypi.python.org/pypi/colorama>`_,
 `argparse (py26) <http://pypi.python.org/pypi/argparse>`_.
 
-**documentation as PDF**: `download latest <http://pytest.org/latest/pytest.pdf>`_
+**documentation as PDF**: `download latest <https://media.readthedocs.org/pdf/pytest/latest/pytest.pdf>`_
 
 .. _`getstarted`:
 .. _installation:

doc/en/index.rst

@@ -10,7 +10,7 @@ pytest: helps you write better programs
  - free and open source software, distributed under the terms of the :ref:`MIT license <license>`
  - **well tested** with more than a thousand tests against itself
  - **strict backward compatibility policy** for safe pytest upgrades
- - :ref:`comprehensive online <toc>` and `PDF documentation <pytest.pdf>`_
+ - :ref:`comprehensive online <toc>` and `PDF documentation <https://media.readthedocs.org/pdf/pytest/latest/pytest.pdf>`_
  - many :ref:`third party plugins <extplugins>` and :ref:`builtin helpers <pytest helpers>`,
  - used in :ref:`many small and large projects and organisations <projects>`
  - comes with many :ref:`tested examples <examples>`