Merge master into features

Several conflicts, mostly due to 2c402f4bd.

Conflicts:
	.pre-commit-config.yaml
	src/_pytest/outcomes.py
	src/_pytest/python_api.py
	tox.ini

doc/en/_templates/globaltoc.html

@@ -4,7 +4,7 @@
   <li><a href="{{ pathto('index') }}">Home</a></li>
   <li><a href="{{ pathto('getting-started') }}">Install</a></li>
   <li><a href="{{ pathto('contents') }}">Contents</a></li>
-  <li><a href="{{ pathto('reference') }}">Reference</a></li>
+  <li><a href="{{ pathto('reference') }}">API Reference</a></li>
   <li><a href="{{ pathto('example/index') }}">Examples</a></li>
   <li><a href="{{ pathto('customize') }}">Customize</a></li>
   <li><a href="{{ pathto('changelog') }}">Changelog</a></li>

doc/en/_themes/flask/layout.html

@@ -16,7 +16,7 @@
 {%- block footer %}
   <div class="footer">
     &copy; Copyright {{ copyright }}.
-    Created using <a href="http://sphinx.pocoo.org/">Sphinx</a>.
+    Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> {{ sphinx_version }}.
   </div>
   {% if pagename == 'index' %}
   </div>

doc/en/_themes/flask/slim_searchbox.html

@@ -0,0 +1,15 @@
+{#
+    basic/searchbox.html with heading removed.
+#}
+{%- if pagename != "search" and builder != "singlehtml" %}
+<div id="searchbox" style="display: none" role="search">
+  <div class="searchformwrapper">
+    <form class="search" action="{{ pathto('search') }}" method="get">
+      <input type="text" name="q" aria-labelledby="searchlabel"
+        placeholder="Search"/>
+      <input type="submit" value="{{ _('Go') }}" />
+    </form>
+  </div>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+{%- endif %}

doc/en/_themes/flask/static/flasky.css_t

@@ -8,11 +8,12 @@
 
 {% set page_width = '1020px' %}
 {% set sidebar_width = '220px' %}
-/* orange of logo is #d67c29 but we use black for links for now */
-{% set link_color = '#000' %}
-{% set link_hover_color = '#000' %}
+/* muted version of green logo color #C9D22A */
+{% set link_color = '#606413' %}
+/* blue logo color */
+{% set link_hover_color = '#009de0' %}
 {% set base_font = 'sans-serif' %}
-{% set header_font = 'serif' %}
+{% set header_font = 'sans-serif' %}
 
 @import url("basic.css");
 
@@ -20,7 +21,7 @@
 
 body {
     font-family: {{ base_font }};
-    font-size: 17px;
+    font-size: 16px;
     background-color: white;
     color: #000;
     margin: 0;
@@ -78,13 +79,13 @@ div.related {
 }
 
 div.sphinxsidebar a {
-    color: #444;
     text-decoration: none;
-    border-bottom: 1px dotted #999;
+    border-bottom: none;
 }
 
 div.sphinxsidebar a:hover {
-    border-bottom: 1px solid #999;
+    color: {{ link_hover_color }};
+    border-bottom: 1px solid {{ link_hover_color }};
 }
 
 div.sphinxsidebar {
@@ -106,14 +107,14 @@ div.sphinxsidebar h3,
 div.sphinxsidebar h4 {
     font-family: {{ header_font }};
     color: #444;
-    font-size: 24px;
+    font-size: 21px;
     font-weight: normal;
-    margin: 0 0 5px 0;
+    margin: 16px 0 0 0;
     padding: 0;
 }
 
 div.sphinxsidebar h4 {
-    font-size: 20px;
+    font-size: 18px;
 }
 
 div.sphinxsidebar h3 a {
@@ -205,10 +206,22 @@ div.body p, div.body dd, div.body li {
     line-height: 1.4em;
 }
 
+ul.simple li {
+    margin-bottom: 0.5em;
+}
+
+div.topic ul.simple li {
+    margin-bottom: 0;
+}
+
+div.topic li > p:first-child {
+    margin-top: 0;
+    margin-bottom: 0;
+}
+
 div.admonition {
     background: #fafafa;
-    margin: 20px -30px;
-    padding: 10px 30px;
+    padding: 10px 20px;
     border-top: 1px solid #ccc;
     border-bottom: 1px solid #ccc;
 }
@@ -217,11 +230,6 @@ div.admonition tt.xref, div.admonition a tt {
     border-bottom: 1px solid #fafafa;
 }
 
-dd div.admonition {
-    margin-left: -60px;
-    padding-left: 60px;
-}
-
 div.admonition p.admonition-title {
     font-family: {{ header_font }};
     font-weight: normal;
@@ -231,7 +239,7 @@ div.admonition p.admonition-title {
     line-height: 1;
 }
 
-div.admonition p.last {
+div.admonition :last-child {
     margin-bottom: 0;
 }
 
@@ -243,7 +251,7 @@ dt:target, .highlight {
     background: #FAF3E8;
 }
 
-div.note {
+div.note, div.warning {
     background-color: #eee;
     border: 1px solid #ccc;
 }
@@ -257,6 +265,11 @@ div.topic {
     background-color: #eee;
 }
 
+div.topic a {
+    text-decoration: none;
+    border-bottom: none;
+}
+
 p.admonition-title {
     display: inline;
 }
@@ -358,21 +371,10 @@ ul, ol {
 
 pre {
     background: #eee;
-    padding: 7px 30px;
-    margin: 15px -30px;
+    padding: 7px 12px;
     line-height: 1.3em;
 }
 
-dl pre, blockquote pre, li pre {
-    margin-left: -60px;
-    padding-left: 60px;
-}
-
-dl dl pre {
-    margin-left: -90px;
-    padding-left: 90px;
-}
-
 tt {
     background-color: #ecf0f3;
     color: #222;
@@ -393,6 +395,20 @@ a.reference:hover {
     border-bottom: 1px solid {{ link_hover_color }};
 }
 
+li.toctree-l1 a.reference,
+li.toctree-l2 a.reference,
+li.toctree-l3 a.reference,
+li.toctree-l4 a.reference {
+    border-bottom: none;
+}
+
+li.toctree-l1 a.reference:hover,
+li.toctree-l2 a.reference:hover,
+li.toctree-l3 a.reference:hover,
+li.toctree-l4 a.reference:hover {
+    border-bottom: 1px solid {{ link_hover_color }};
+}
+
 a.footnote-reference {
     text-decoration: none;
     font-size: 0.7em;
@@ -408,6 +424,56 @@ a:hover tt {
     background: #EEE;
 }
 
+#reference div.section h2 {
+    /* separate code elements in the reference section */
+    border-top: 2px solid #ccc;
+    padding-top: 0.5em;
+}
+
+#reference div.section h3 {
+    /* separate code elements in the reference section */
+    border-top: 1px solid #ccc;
+    padding-top: 0.5em;
+}
+
+dl.class, dl.function {
+    margin-top: 1em;
+    margin-bottom: 1em;
+}
+
+dl.class > dd {
+    border-left: 3px solid #ccc;
+    margin-left: 0px;
+    padding-left: 30px;
+}
+
+dl.field-list {
+    flex-direction: column;
+}
+
+dl.field-list dd {
+    padding-left: 4em;
+    border-left: 3px solid #ccc;
+    margin-bottom: 0.5em;
+}
+
+dl.field-list dd > ul {
+    list-style: none;
+    padding-left: 0px;
+}
+
+dl.field-list dd > ul > li li :first-child {
+    text-indent: 0;
+}
+
+dl.field-list dd > ul > li :first-child {
+    text-indent: -2em;
+    padding-left: 0px;
+}
+
+dl.field-list dd > p:first-child {
+    text-indent: -2em;
+}
 
 @media screen and (max-width: 870px) {
 

doc/en/adopt.rst

@@ -24,11 +24,9 @@ The ideal pytest helper
  - feels confident in using pytest (e.g. has explored command line options, knows how to write parametrized tests, has an idea about conftest contents)
  - does not need to be an expert in every aspect!
 
-`Pytest helpers, sign up here`_! (preferably in February, hard deadline 22 March)
+Pytest helpers, sign up here! (preferably in February, hard deadline 22 March)
 
 
-.. _`Pytest helpers, sign up here`: http://goo.gl/forms/nxqAhqWt1P
-
 
 The ideal partner project
 -----------------------------------------
@@ -40,11 +38,9 @@ The ideal partner project
  - has the support of the core development team, in trying out pytest adoption
  - has no tests... or 100% test coverage... or somewhere in between!
 
-`Partner projects, sign up here`_! (by 22 March)
+Partner projects, sign up here! (by 22 March)
 
 
-.. _`Partner projects, sign up here`:  http://goo.gl/forms/ZGyqlHiwk3
-
 
 What does it mean to "adopt pytest"?
 -----------------------------------------
@@ -68,11 +64,11 @@ Progressive success might look like:
 It may be after the month is up, the partner project decides that pytest is not right for it. That's okay - hopefully the pytest team will also learn something about its weaknesses or deficiencies.
 
 .. _`nose and unittest`: faq.html#how-does-pytest-relate-to-nose-and-unittest
-.. _assert: asserts.html
+.. _assert: assert.html
 .. _pycmd: https://bitbucket.org/hpk42/pycmd/overview
 .. _`setUp/tearDown methods`: xunit_setup.html
 .. _fixtures: fixture.html
-.. _markers: markers.html
+.. _markers: mark.html
 .. _distributed: xdist.html
 
 

doc/en/announce/release-2.1.0.rst

@@ -12,7 +12,7 @@ courtesy of Benjamin Peterson.  You can now safely use ``assert``
 statements in test modules without having to worry about side effects
 or python optimization ("-OO") options.  This is achieved by rewriting
 assert statements in test modules upon import, using a PEP302 hook.
-See http://pytest.org/assert.html#advanced-assertion-introspection for
+See https://docs.pytest.org/en/latest/assert.html for
 detailed information.  The work has been partly sponsored by my company,
 merlinux GmbH.
 

doc/en/announce/release-2.9.0.rst

@@ -75,7 +75,7 @@ The py.test Development Team
 
 **Changes**
 
-* **Important**: `py.code <https://pylib.readthedocs.io/en/latest/code.html>`_ has been
+* **Important**: `py.code <https://pylib.readthedocs.io/en/stable/code.html>`_ has been
   merged into the ``pytest`` repository as ``pytest._code``. This decision
   was made because ``py.code`` had very few uses outside ``pytest`` and the
   fact that it was in a different repository made it difficult to fix bugs on
@@ -88,7 +88,7 @@ The py.test Development Team
   **experimental**, so you definitely should not import it explicitly!
 
   Please note that the original ``py.code`` is still available in
-  `pylib <https://pylib.readthedocs.io>`_.
+  `pylib <https://pylib.readthedocs.io/en/stable/>`_.
 
 * ``pytest_enter_pdb`` now optionally receives the pytest config object.
   Thanks `@nicoddemus`_ for the PR.

doc/en/announce/release-2.9.2.rst

@@ -66,8 +66,8 @@ The py.test Development Team
 
 .. _#510: https://github.com/pytest-dev/pytest/issues/510
 .. _#1506: https://github.com/pytest-dev/pytest/pull/1506
-.. _#1496: https://github.com/pytest-dev/pytest/issue/1496
-.. _#1524: https://github.com/pytest-dev/pytest/issue/1524
+.. _#1496: https://github.com/pytest-dev/pytest/issues/1496
+.. _#1524: https://github.com/pytest-dev/pytest/pull/1524
 
 .. _@astraw38: https://github.com/astraw38
 .. _@hackebrot: https://github.com/hackebrot

doc/en/conf.py

@@ -15,7 +15,6 @@
 #
 # The full version, including alpha/beta/rc tags.
 # The short X.Y version.
-import datetime
 import os
 import sys
 
@@ -63,8 +62,7 @@ master_doc = "contents"
 
 # General information about the project.
 project = "pytest"
-year = datetime.datetime.utcnow().year
-copyright = "2015–2019 , holger krekel and pytest-dev team"
+copyright = "2015–2019, holger krekel and pytest-dev team"
 
 
 # The language for content autogenerated by Sphinx. Refer to documentation
@@ -167,18 +165,18 @@ html_favicon = "img/pytest1favi.ico"
 
 html_sidebars = {
     "index": [
+        "slim_searchbox.html",
         "sidebarintro.html",
         "globaltoc.html",
         "links.html",
         "sourcelink.html",
-        "searchbox.html",
     ],
     "**": [
+        "slim_searchbox.html",
         "globaltoc.html",
         "relations.html",
         "links.html",
         "sourcelink.html",
-        "searchbox.html",
     ],
 }
 

doc/en/example/fixtures/test_fixtures_order.py

@@ -0,0 +1,38 @@
+import pytest
+
+# fixtures documentation order example
+order = []
+
+
+@pytest.fixture(scope="session")
+def s1():
+    order.append("s1")
+
+
+@pytest.fixture(scope="module")
+def m1():
+    order.append("m1")
+
+
+@pytest.fixture
+def f1(f3):
+    order.append("f1")
+
+
+@pytest.fixture
+def f3():
+    order.append("f3")
+
+
+@pytest.fixture(autouse=True)
+def a1():
+    order.append("a1")
+
+
+@pytest.fixture
+def f2():
+    order.append("f2")
+
+
+def test_order(f1, m1, f2, s1):
+    assert order == ["s1", "m1", "a1", "f3", "f1", "f2"]

doc/en/example/markers.rst

@@ -336,7 +336,7 @@ apply a marker to an individual test instance:
 
     @pytest.mark.foo
     @pytest.mark.parametrize(
-        ("n", "expected"), [(1, 2), pytest.param((1, 3), marks=pytest.mark.bar), (2, 3)]
+        ("n", "expected"), [(1, 2), pytest.param(1, 3, marks=pytest.mark.bar), (2, 3)]
     )
     def test_increment(n, expected):
         assert n + 1 == expected

doc/en/example/parametrize.rst

@@ -552,13 +552,13 @@ Then run ``pytest`` with verbose mode and with only the ``basic`` marker:
     platform linux -- Python 3.x.y, pytest-5.x.y, py-1.x.y, pluggy-0.x.y -- $PYTHON_PREFIX/bin/python
     cachedir: $PYTHON_PREFIX/.pytest_cache
     rootdir: $REGENDOC_TMPDIR
-    collecting ... collected 17 items / 14 deselected / 3 selected
+    collecting ... collected 18 items / 15 deselected / 3 selected
 
     test_pytest_param_example.py::test_eval[1+7-8] PASSED                [ 33%]
     test_pytest_param_example.py::test_eval[basic_2+4] PASSED            [ 66%]
     test_pytest_param_example.py::test_eval[basic_6*9] XFAIL             [100%]
 
-    ============ 2 passed, 14 deselected, 1 xfailed in 0.12 seconds ============
+    ============ 2 passed, 15 deselected, 1 xfailed in 0.12 seconds ============
 
 As the result:
 

doc/en/fixture.rst

@@ -289,51 +289,29 @@ are finalized when the last test of a *package* finishes.
     Use this new feature sparingly and please make sure to report any issues you find.
 
 
-Higher-scoped fixtures are instantiated first
----------------------------------------------
+Order: Higher-scoped fixtures are instantiated first
+----------------------------------------------------
 
 
 
 Within a function request for features, fixture of higher-scopes (such as ``session``) are instantiated first than
 lower-scoped fixtures (such as ``function`` or ``class``). The relative order of fixtures of same scope follows
-the declared order in the test function and honours dependencies between fixtures.
+the declared order in the test function and honours dependencies between fixtures. Autouse fixtures will be
+instantiated before explicitly used fixtures.
 
 Consider the code below:
 
-.. code-block:: python
-
-    @pytest.fixture(scope="session")
-    def s1():
-        pass
-
-
-    @pytest.fixture(scope="module")
-    def m1():
-        pass
-
-
-    @pytest.fixture
-    def f1(tmpdir):
-        pass
-
-
-    @pytest.fixture
-    def f2():
-        pass
-
-
-    def test_foo(f1, m1, f2, s1):
-        ...
-
+.. literalinclude:: example/fixtures/test_fixtures_order.py
 
 The fixtures requested by ``test_foo`` will be instantiated in the following order:
 
 1. ``s1``: is the highest-scoped fixture (``session``).
 2. ``m1``: is the second highest-scoped fixture (``module``).
-3. ``tmpdir``: is a ``function``-scoped fixture, required by ``f1``: it needs to be instantiated at this point
-   because it is a dependency of ``f1``.
-4. ``f1``: is the first ``function``-scoped fixture in ``test_foo`` parameter list.
-5. ``f2``: is the last ``function``-scoped fixture in ``test_foo`` parameter list.
+3. ``a1``: is a ``function``-scoped ``autouse`` fixture: it will be instantiated before other fixtures
+   within the same scope.
+4. ``f3``: is a ``function``-scoped fixture, required by ``f1``: it needs to be instantiated at this point
+5. ``f1``: is the first ``function``-scoped fixture in ``test_foo`` parameter list.
+6. ``f2``: is the last ``function``-scoped fixture in ``test_foo`` parameter list.
 
 
 .. _`finalization`:
@@ -400,6 +378,34 @@ The ``smtp_connection`` connection will be closed after the test finished
 execution because the ``smtp_connection`` object automatically closes when
 the ``with`` statement ends.
 
+Using the contextlib.ExitStack context manager finalizers will always be called
+regardless if the fixture *setup* code raises an exception. This is handy to properly
+close all resources created by a fixture even if one of them fails to be created/acquired:
+
+.. code-block:: python
+
+    # content of test_yield3.py
+
+    import contextlib
+
+    import pytest
+
+
+    @contextlib.contextmanager
+    def connect(port):
+        ...  # create connection
+        yield
+        ...  # close connection
+
+
+    @pytest.fixture
+    def equipments():
+        with contextlib.ExitStack() as stack:
+            yield [stack.enter_context(connect(port)) for port in ("C1", "C3", "C28")]
+
+In the example above, if ``"C28"`` fails with an exception, ``"C1"`` and ``"C3"`` will still
+be properly closed.
+
 Note that if an exception happens during the *setup* code (before the ``yield`` keyword), the
 *teardown* code (after the ``yield``) will not be called.
 
@@ -428,27 +434,39 @@ Here's the ``smtp_connection`` fixture changed to use ``addfinalizer`` for clean
         return smtp_connection  # provide the fixture value
 
 
+Here's the ``equipments`` fixture changed to use ``addfinalizer`` for cleanup:
+
+.. code-block:: python
+
+    # content of test_yield3.py
+
+    import contextlib
+    import functools
+
+    import pytest
+
+
+    @contextlib.contextmanager
+    def connect(port):
+        ...  # create connection
+        yield
+        ...  # close connection
+
+
+    @pytest.fixture
+    def equipments(request):
+        r = []
+        for port in ("C1", "C3", "C28"):
+            cm = connect(port)
+            equip = cm.__enter__()
+            request.addfinalizer(functools.partial(cm.__exit__, None, None, None))
+            r.append(equip)
+        return r
+
+
 Both ``yield`` and ``addfinalizer`` methods work similarly by calling their code after the test
-ends, but ``addfinalizer`` has two key differences over ``yield``:
-
-1. It is possible to register multiple finalizer functions.
-
-2. Finalizers will always be called regardless if the fixture *setup* code raises an exception.
-   This is handy to properly close all resources created by a fixture even if one of them
-   fails to be created/acquired::
-
-        @pytest.fixture
-        def equipments(request):
-            r = []
-            for port in ('C1', 'C3', 'C28'):
-                equip = connect(port)
-                request.addfinalizer(equip.disconnect)
-                r.append(equip)
-            return r
-
-   In the example above, if ``"C28"`` fails with an exception, ``"C1"`` and ``"C3"`` will still
-   be properly closed. Of course, if an exception happens before the finalize function is
-   registered then it will not be executed.
+ends. Of course, if an exception happens before the finalize function is registered then it
+will not be executed.
 
 
 .. _`request-context`:
@@ -522,7 +540,7 @@ of a fixture is needed multiple times in a single test. Instead of returning
 data directly, the fixture instead returns a function which generates the data.
 This function can then be called multiple times in the test.
 
-Factories can have have parameters as needed::
+Factories can have parameters as needed::
 
     @pytest.fixture
     def make_customer_record():

doc/en/flaky.rst

@@ -122,4 +122,4 @@ Resources
 * Google:
 
   * `Flaky Tests at Google and How We Mitigate Them <https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html>`_ by John Micco, 2016
-  * `Where do Google's flaky tests come from? <https://docs.google.com/document/d/1mZ0-Kc97DI_F3tf_GBW_NB_aqka-P1jVOsFfufxqUUM/edit#heading=h.ec0r4fypsleh>`_  by Jeff Listfield, 2017
+  * `Where do Google's flaky tests come from? <https://testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html>`_  by Jeff Listfield, 2017

doc/en/getting-started.rst

@@ -142,7 +142,7 @@ The first test passed and the second failed. You can easily see the intermediate
 Request a unique temporary directory for functional tests
 --------------------------------------------------------------
 
-``pytest`` provides `Builtin fixtures/function arguments <https://docs.pytest.org/en/latest/builtin.html#builtinfixtures>`_ to request arbitrary resources, like a unique temporary directory::
+``pytest`` provides `Builtin fixtures/function arguments <https://docs.pytest.org/en/latest/builtin.html>`_ to request arbitrary resources, like a unique temporary directory::
 
     # content of test_tmpdir.py
     def test_needsfiles(tmpdir):

doc/en/index.rst

@@ -61,7 +61,7 @@ Features
 
 - Can run :ref:`unittest <unittest>` (including trial) and :ref:`nose <noseintegration>` test suites out of the box;
 
-- Python Python 3.5+ and PyPy 3;
+- Python 3.5+ and PyPy 3;
 
 - Rich plugin architecture, with over 315+ `external plugins <http://plugincompat.herokuapp.com>`_ and thriving community;
 

doc/en/license.rst

@@ -9,7 +9,7 @@ Distributed under the terms of the `MIT`_ license, pytest is free and open sourc
 
     The MIT License (MIT)
 
-    Copyright (c) 2004-2017 Holger Krekel and others
+    Copyright (c) 2004-2019 Holger Krekel and others
 
     Permission is hereby granted, free of charge, to any person obtaining a copy of
     this software and associated documentation files (the "Software"), to deal in

doc/en/links.inc

@@ -14,7 +14,7 @@
 .. _`distribute docs`:
 .. _`distribute`: https://pypi.org/project/distribute/
 .. _`pip`: https://pypi.org/project/pip/
-.. _`venv`: https://docs.python.org/3/library/venv.html/
+.. _`venv`: https://docs.python.org/3/library/venv.html
 .. _`virtualenv`: https://pypi.org/project/virtualenv/
 .. _hudson: http://hudson-ci.org/
 .. _jenkins: http://jenkins-ci.org/

doc/en/mark.rst

@@ -40,7 +40,7 @@ You can register custom marks in your ``pytest.ini`` file like this:
 
 Note that everything after the ``:`` is an optional description.
 
-Alternatively, you can register new markers programatically in a
+Alternatively, you can register new markers programmatically in a
 :ref:`pytest_configure <initialization-hooks>` hook:
 
 .. code-block:: python

doc/en/monkeypatch.rst

@@ -46,10 +46,13 @@ environment variable is missing, or to set multiple values to a known variable.
 :py:meth:`monkeypatch.setenv` and :py:meth:`monkeypatch.delenv` can be used for
 these patches.
 
-4. Use :py:meth:`monkeypatch.syspath_prepend` to modify the system ``$PATH`` safely, and
+4. Use ``monkeypatch.setenv("PATH", value, prepend=os.pathsep)`` to modify ``$PATH``, and
 :py:meth:`monkeypatch.chdir` to change the context of the current working directory
 during a test.
 
+5. Use py:meth:`monkeypatch.syspath_prepend` to modify ``sys.path`` which will also
+call :py:meth:`pkg_resources.fixup_namespace_packages` and :py:meth:`importlib.invalidate_caches`.
+
 See the `monkeypatch blog post`_ for some introduction material
 and a discussion of its motivation.
 

doc/en/projects.rst

@@ -28,7 +28,6 @@ Here are some examples of projects using ``pytest`` (please send notes via :ref:
 * `sentry <https://getsentry.com/welcome/>`_, realtime app-maintenance and exception tracking
 * `Astropy <http://www.astropy.org/>`_ and `affiliated packages <http://www.astropy.org/affiliated/index.html>`_
 * `tox <http://testrun.org/tox>`_, virtualenv/Hudson integration tool
-* `PIDA <http://pida.co.uk>`_ framework for integrated development
 * `PyPM <http://code.activestate.com/pypm/>`_ ActiveState's package manager
 * `Fom <http://packages.python.org/Fom/>`_ a fluid object mapper for FluidDB
 * `applib <https://github.com/ActiveState/applib>`_ cross-platform utilities
@@ -37,8 +36,7 @@ Here are some examples of projects using ``pytest`` (please send notes via :ref:
 * `mwlib <https://pypi.org/project/mwlib/>`_ mediawiki parser and utility library
 * `The Translate Toolkit <http://translate.sourceforge.net/wiki/toolkit/index>`_ for localization and conversion
 * `execnet <http://codespeak.net/execnet>`_ rapid multi-Python deployment
-* `pylib <https://py.readthedocs.io>`_ cross-platform path, IO, dynamic code library
-* `Pacha <http://pacha.cafepais.com/>`_ configuration management in five minutes
+* `pylib <https://pylib.readthedocs.io/en/stable/>`_ cross-platform path, IO, dynamic code library
 * `bbfreeze <https://pypi.org/project/bbfreeze/>`_ create standalone executables from Python scripts
 * `pdb++ <http://bitbucket.org/antocuni/pdb>`_ a fancier version of PDB
 * `py-s3fuse <http://code.google.com/p/py-s3fuse/>`_ Amazon S3 FUSE based filesystem
@@ -77,7 +75,7 @@ Some organisations using pytest
 * `Tandberg <http://www.tandberg.com/>`_
 * `Shootq <http://web.shootq.com/>`_
 * `Stups department of Heinrich Heine University Duesseldorf <http://www.stups.uni-duesseldorf.de/projects.php>`_
-* `cellzome <http://www.cellzome.com/>`_
+* cellzome
 * `Open End, Gothenborg <http://www.openend.se>`_
 * `Laboratory of Bioinformatics, Warsaw <http://genesilico.pl/>`_
 * `merlinux, Germany <http://merlinux.eu>`_

doc/en/reference.rst

@@ -1,5 +1,5 @@
-Reference
-=========
+API Reference
+=============
 
 This page contains the full reference to pytest's API.
 

doc/en/talks.rst

@@ -4,9 +4,8 @@ Talks and Tutorials
 
 .. sidebar:: Next Open Trainings
 
-   - `Training at Europython 2019 <https://ep2019.europython.eu/talks/94WEnsY-introduction-to-pytest/>`_, 8th July 2019, Basel, Switzerland.
-
    - `Training at Workshoptage 2019 <https://workshoptage.ch/workshops/2019/test-driven-development-fuer-python-mit-pytest/>`_ (German), 10th September 2019, Rapperswil, Switzerland.
+   - `3 day hands-on workshop covering pytest, tox and devpi: "Professional Testing with Python" <https://python-academy.com/courses/specialtopics/python_course_testing.html>`_ (English), October 21 - 23, 2019, Leipzig, Germany.
 
 .. _`funcargs`: funcargs.html
 

doc/en/warnings.rst

@@ -127,7 +127,7 @@ decorator or to all tests in a module by setting the ``pytestmark`` variable:
 *Credits go to Florian Schulze for the reference implementation in the* `pytest-warnings`_
 *plugin.*
 
-.. _`-W option`: https://docs.python.org/3/using/cmdline.html?highlight=#cmdoption-W
+.. _`-W option`: https://docs.python.org/3/using/cmdline.html#cmdoption-w
 .. _warnings.simplefilter: https://docs.python.org/3/library/warnings.html#warnings.simplefilter
 .. _`pytest-warnings`: https://github.com/fschulze/pytest-warnings
 

doc/en/writing_plugins.rst

@@ -164,7 +164,7 @@ If a package is installed this way, ``pytest`` will load
 .. note::
 
     Make sure to include ``Framework :: Pytest`` in your list of
-    `PyPI classifiers <https://python-packaging-user-guide.readthedocs.io/distributing/#classifiers>`_
+    `PyPI classifiers <https://pypi.org/classifiers/>`_
     to make it easy for users to find your plugin.