[YANKED] pytest 8.1.0 removes many deprecations, but not mentioned in changelog

[mr-c]

#11757 is not mentioned as a breaking change for the Pytest 8.1.0 Release in https://docs.pytest.org/en/stable/changelog.html ; it breaks plugins who were still supporting the older signature.

I'm opening this issue as a hint to others; is it possible to update the changelog after a release?

[RonnyPfannschmidt]

this is a duplicate of #12068

the removal process itself is as intended, the oversight was that warnings of certain hooks where not displayed as expected

leaving this open for now to help people
the fact that it wasn't failing on 8.0 is the actual bug

[bluetech]

@RonnyPfannschmidt @nicoddemus since we botched the deprecation, perhaps we should revert the removal until we can have at least one release with proper deprecation?

[RonnyPfannschmidt]

should we yank 8.1 for the deprecation issues?

[RonnyPfannschmidt]

lets defer the return of code a bit as i'd like to know first how to trigger the errors

[nicoddemus]

I think it is fair to postpone the removals if we did not issue the proper warnings, as we vouch to do before any removals took place.

Those removals would then have to be postponed to 9.0/9.1 then.

Not sure if you folks would like to yank 8.1? Seems reasonable.

[bluetech]

Reverting + releasing 8.1.1 should not be a problem, but if @RonnyPfannschmidt wants to avoid a revert, let's yank as it seems to be causing a lot of failures.

[RonnyPfannschmidt]

lets yank and revert then

[nicoddemus]

I'm yanking it.

[nicoddemus]

[bluetech]

Thanks @nicoddemus!

@RonnyPfannschmidt do you want me to revert the removal, or do you want to?

[nicoddemus]

Opening PR to update the CHANGELOG.

[mr-c]

Dear maintainers and devs, thank you for all that you do and the quick response! 💖

[alexted]

But in retrospect we probably should not have yanked the release.

Yanking should be used only in situations where the released package is broken/unusable, when (almost) every installation of the package will break the environment and/or runtime. In this case we only broke some plugins, but users not using those plugins were unaffected.

Live and learn I guess.

Apparently, you were overnervous that you withdrew this version )))

[RonnyPfannschmidt]

I still hold the opinion that yanking a release that enacts breakages whose warning where missing is a correct course of action

However I wasn't aware of wrongly overzealous compatibility pins, so in future I'll ensure a quick fix in the affected line is available for affected Parties

[sigma67]

Edit: it seems I misunderstood how yanking works.

https://peps.python.org/pep-0592

[bluetech]

@sigma67 No, if you pin the exact version, it should successfully install even if yanked. This is the famous "left-pad" issue.

[nicoddemus]

@bluetech is correct AIFAK: yanking is not removing, the package is still available if you explicitly ask for it, for example:

λ pip install pytest==8.1.0
Collecting pytest==8.1.0
  Using cached pytest-8.1.0-py3-none-any.whl.metadata (7.6 kB)
Collecting iniconfig (from pytest==8.1.0)
  Using cached iniconfig-2.0.0-py3-none-any.whl.metadata (2.6 kB)
Requirement already satisfied: packaging in .\.env310\lib\site-packages (from pytest==8.1.0) (23.2)
Collecting pluggy<2.0,>=1.4 (from pytest==8.1.0)
  Using cached pluggy-1.4.0-py3-none-any.whl.metadata (4.3 kB)
Collecting exceptiongroup>=1.0.0rc8 (from pytest==8.1.0)
  Using cached exceptiongroup-1.2.0-py3-none-any.whl.metadata (6.6 kB)
Collecting tomli>=1 (from pytest==8.1.0)
  Using cached tomli-2.0.1-py3-none-any.whl.metadata (8.9 kB)
Collecting colorama (from pytest==8.1.0)
  Using cached colorama-0.4.6-py2.py3-none-any.whl.metadata (17 kB)
WARNING: The candidate selected for download or install is a yanked version: 'pytest' candidate (version 8.1.0 at https://files.pythonhosted.org/packages/5a/4a/3f626e3974bea1e6d471bd86f7965c67cd06d5770d1fec9aae445c44da7b/pytest-8.1.0-py3-none-any.whl (from https://pypi.org/simple/pytest/) (requires-python:>=3.8))
Reason for being yanked: See https://github.com/pytest-dev/pytest/issues/12069
Using cached pytest-8.1.0-py3-none-any.whl (335 kB)
Using cached exceptiongroup-1.2.0-py3-none-any.whl (16 kB)
Using cached pluggy-1.4.0-py3-none-any.whl (20 kB)
Using cached tomli-2.0.1-py3-none-any.whl (12 kB)
Using cached colorama-0.4.6-py2.py3-none-any.whl (25 kB)
Using cached iniconfig-2.0.0-py3-none-any.whl (5.9 kB)
Installing collected packages: tomli, pluggy, iniconfig, exceptiongroup, colorama, pytest
Successfully installed colorama-0.4.6 exceptiongroup-1.2.0 iniconfig-2.0.0 pluggy-1.4.0 pytest-8.1.0 tomli-2.0.1

Even though 8.1.0 was yanked -- locked dependencies should be fine then.

[edgarrmondragon]

Yup, I can confirm that poetry-locked yanked dependencies install just fine and merely emit a warning

[iurisilvio]

Is it expected to 8.1.1 proper warn about the deprecation?

The pytest-ruff don't trigger any deprecation warning. I don't know if it is expected or if I have to test it better.

[bluetech]

@iurisilvio No, we still need to work on fixing the deprecation.

[bluetech]

But you can test with the yanked 8.1.0 for now, if it works you're clear 😄

[iurisilvio]

Thanks! I'll test with 8.1.0!

[bwoodsend]

8.1.1 didn't revert all the removals, right? The _pytest.runner.call_runtest_hook removal is still waiving at me insistently using pytest 8.1.1.

Edit: I've remembered that that's private API so I guess it gets the well what did you expect? treatment.

[nicoddemus]

No, we only reverted those two removals:

• fspath argument for Node constructors replaced with pathlib.Path
• py.path.local arguments for hooks replaced with pathlib.Path.

The rationale being that we were not warning about those deprecations.

call_runtest_hook was never deprecated because it was an internal API, which we do not guarantee stability across releases.

I guess it gets the well what did you expect? treatment.

Well perhaps not being so harsh 😁, but yes, we reserve the right to break those when we improve the internal code.