Preparing release version 4.1.2

[nicoddemus]

No description provided.

[nicoddemus]

Weird, @asottile we are getting an error during doc generation:

Warning, treated as error:
/home/travis/build/pytest-dev/pytest/doc/en/example/parametrize.rst:539:Could not lex literal_block as "pytest". Highlighting skipped.
ERROR: InvocationError for command '/home/travis/build/pytest-dev/pytest/.tox/docs/bin/sphinx-build -W -b html . _build' (exited with code 2)

Here's the relevant code:

.. code-block:: pytest

    $ pytest -v -m basic
    =========================== test session starts ============================
    platform linux -- Python 3.x.y, pytest-4.x.y, py-1.x.y, pluggy-0.x.y -- $PYTHON_PREFIX/bin/python3.6
    cachedir: .pytest_cache
    rootdir: $REGENDOC_TMPDIR, inifile:
    collecting ... collected 17 items / 14 deselected

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

This is not new and just now started to fail... any ideas?

[asottile]

interesting, let me take a look

[asottile]

there's a difference in output between pytest 4.1.1 and master -- I suspect we should fix that and not release:

import pytest


@pytest.mark.xfail
def test_xfail():
    raise AssertionError()


@pytest.mark.xfail
def test_xpass():
    pass

pytest t.py -vv > 4_1_1
pip install git+https://github.com/pytest-dev/pytest --upgrade
pytest t.py -vv > 4_1_2

$ diff -u 4_1_1 4_1_2 
--- 4_1_1	2019-01-28 13:38:03.004458708 -0800
+++ 4_1_2	2019-01-28 13:38:18.108019589 -0800
@@ -1,10 +1,10 @@
 ============================= test session starts ==============================
-platform linux -- Python 3.6.7, pytest-4.1.1, py-1.7.0, pluggy-0.8.1 -- /tmp/pygments-pytest/venv/bin/python3
+platform linux -- Python 3.6.7, pytest-4.1.2.dev39+g5119abe4, py-1.7.0, pluggy-0.8.1 -- /tmp/pygments-pytest/venv/bin/python3
 cachedir: .pytest_cache
 rootdir: /tmp/pygments-pytest, inifile:
 collecting ... collected 2 items
 
-t.py::test_xfail xfail                                                   [ 50%]
+t.py::test_xfail XFAIL                                                   [ 50%]
 t.py::test_xpass XPASS                                                   [100%]
 
 ===================== 1 xfailed, 1 xpassed in 0.02 seconds =====================

The original behaviour seems more correct to me, for xfail we used x / xfail for "failed and expected to fail" and X / XPASS for "passed but expected to fail"

[nicoddemus]

Hmm right, this was changed in #4668. I disagree, I think XFAIL is more consistent with all the other statuses we display: PASSED, FAILED, XPASS, SKIPPED. It is odd that only xfail was not in caps.

[asottile]

🤷‍♂️ 1a8b283 changed xpass to XPASS without changing XFAIL making me think it was intentional to match the case of the short status.

It's entirely cosmetic though I guess -- I can update pygments-pytest to recognize XFAIL as well -- let me know how you'd like to proceed :)

[nicoddemus]

I can update pygments-pytest to recognize XFAIL as well -- let me know how you'd like to proceed :)

Yes please. ☺️

[asottile]

the other question is should this change land in 4.1.2 or in 4.2.0

[asottile]

here's the patch for XFAIL: pytest-dev/pygments-pytest#11

[nicoddemus]

the other question is should this change land in 4.1.2 or in 4.2.0

Hmmm I guess this small change is OK to go into 4.1.2. @RonnyPfannschmidt what's your opinion on this?

[asottile]

pygments-pytest>=1.1.1. supports XFAIL (capitalized)

[codecov]

Codecov Report

Merging #4686 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4686      +/-   ##
==========================================
+ Coverage   95.71%   95.71%   +<.01%     
==========================================
  Files         113      113              
  Lines       24907    24907              
  Branches     2459     2459              
==========================================
+ Hits        23839    23840       +1     
  Misses        755      755              
+ Partials      313      312       -1

Flag	Coverage Δ
#docs	29.57% <ø> (+0.07%)	⬆️
#doctesting	29.57% <ø> (+0.07%)	⬆️
#linting	29.57% <ø> (+0.07%)	⬆️
#linux	95.53% <ø> (ø)	⬆️
#nobyte	92.33% <ø> (ø)	⬆️
#numpy	93.14% <ø> (ø)	⬆️
#pexpect	42.08% <ø> (ø)	⬆️
#py27	93.72% <ø> (+0.02%)	⬆️
#py34	91.82% <ø> (+0.06%)	⬆️
#py35	91.84% <ø> (+0.06%)	⬆️
#py36	91.87% <ø> (+0.06%)	⬆️
#py37	93.85% <ø> (ø)	⬆️
#trial	93.14% <ø> (ø)	⬆️
#windows	93.92% <ø> (ø)	⬆️
#xdist	93.74% <ø> (ø)	⬆️

Impacted Files	Coverage Δ
src/_pytest/cacheprovider.py	97.16% <0%> (+0.47%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5119abe...bb3f35f. Read the comment docs.

[nicoddemus]

Awesome, thanks @asottile! 🙇

[blueyed]

the other question is should this change land in 4.1.2 or in 4.2.0

Hmmm I guess this small change is OK to go into 4.1.2. @RonnyPfannschmidt what's your opinion on this?

I think the problem with pygments-pytest shows that it might cause problems with other tools that are parsing the output, so I'd vote for holding it back for 4.2.0 - or release this as 4.2.0?!

[nicoddemus]

Yeah, I agree, so I'm closing this.

[nicoddemus]

We have only 3 issues left on the 4.2 milestone, seems reasonable that we can get 4.2 out by the end of the week?

[blueyed]

I do not have much time myself, but #4280 should be fine - no real review though still.

[nicoddemus]

@blueyed I will take it for a spin later and merge it, unless I encounter some problem. 👍

[wimglenn]

The 1a8b283 might be the historical reason I was searching for in #4668 (comment)
This change should certainly not go in a micro release bump (it's very likely some users are parsing those test report output statuses with case sensitivite greps or whatever).