(fspath: py.path.local) argument to BlackItem is deprecated

[nadamoukaddem]

When running pytest on the test file src/wf_psf/tests/train_test.py, I encountered the following error:

`_ ERROR collecting src/wf_psf __ ../.local/lib/python3.10/site-packages/_pytest/nodes.py:152: in _create return super().call(*k, **kw) E TypeError: BlackItem.init() got an unexpected keyword argument 'path'

During handling of the above exception, another exception occurred: ../.local/lib/python3.10/site-packages/pluggy/_hooks.py:501: in call return self._hookexec(self.name, self._hookimpls.copy(), kwargs, firstresult) ../.local/lib/python3.10/site-packages/pluggy/_manager.py:119: in _hookexec return self._inner_hookexec(hook_name, methods, kwargs, firstresult) ../.local/lib/python3.10/site-packages/pytest_black.py:27: in pytest_collect_file return BlackItem.from_parent(parent, fspath=path) ../.local/lib/python3.10/site-packages/_pytest/nodes.py:661: in from_parent return super().from_parent(parent=parent, fspath=fspath, path=path, kw) ../.local/lib/python3.10/site-packages/_pytest/nodes.py:275: in from_parent return cls._create(parent=parent, kw) ../.local/lib/python3.10/site-packages/_pytest/nodes.py:167: in _create return super().call(*k, **known_kw) ../.local/lib/python3.10/site-packages/pytest_black.py:47: in init super(BlackItem, self).init(fspath, parent) ../.local/lib/python3.10/site-packages/_pytest/nodes.py:718: in init super().init( ../.local/lib/python3.10/site-packages/_pytest/nodes.py:616: in init path = _imply_path(type(self), path, fspath=fspath) ../.local/lib/python3.10/site-packages/_pytest/nodes.py:108: in _imply_path warnings.warn( E pytest.PytestRemovedIn8Warning: The (fspath: py.path.local) argument to BlackItem is deprecated. Please use the (path: pathlib.Path) argument instead. E See https://docs.pytest.org/en/latest/deprecations.html#fspath-argument-for-node-constructors-replaced-with-pathlib-path

[nadamoukaddem]

Hi @jeipollack, does the automatic testing with pytest use a different Python version (3.10.5) compared to WaveDiff (3.10.12) ?

[jeipollack]

Hi @jeipollack, does the automatic testing with pytest use a different Python version (3.10.5) compared to WaveDiff (3.10.12) ?

Are you speaking about the CI testing? You can check the logs to see what versions of python was used.

[nadamoukaddem]

Hi @jeipollack, does the automatic testing with pytest use a different Python version (3.10.5) compared to WaveDiff (3.10.12) ?

Are you speaking about the CI testing? You can check the logs to see what versions of python was used.

The pytest tests are currently running, but some files are failing the black test in the CI testing, which is not the case locally.

[jeipollack]

Okay, do you think you can figure out and resolve why they are failing or do you think you need my help?

[nadamoukaddem]

Yes, I think I need your help because I didn't make any changes to these files, so I'm unsure why I'm encountering this error.

[jeipollack]

This is a good case to put into practice our issue template. You should share the error messages you're getting in this issue, so I or someone can have a look.

[nadamoukaddem]

Ok this issue #118 was solved by fixing the pytest version to 7.4.4 so I will open another one to describe the new error.

[jeipollack]

It's good you found a working version, but that doesn't really answer the original question of whether the version of pytest-black available in PyPi.org is up to date with its codebase (in its original repository). This is what Sam asked for you to check.

Basically, check if the codebase is being maintained by looking at the last updates, reported issues, the version of python or pytest. You can even try to look at the last release of the plugin to spot the cause of the error.

I've given you some clues, as a learning experience into diagnosing and debugging.

If you have questions or don't understand let me know by replying to this message.

[jeipollack]

Hi @nadamoukaddem, checking in to see how you're progressing with this check. Do you have any updates?

[nadamoukaddem]

Hi @jeipollack, I haven't figured out how to solve this yet. In the issues, it was mentioned that pytest-cases isn't compatible with pytest, but disabling it didn't solve the problem. Also, when I disabled each plugin individually, the error persisted ! After reviewing the issues reported for different plugins, I still couldn't find a solution. Meanwhile, I'm focusing on resolving issue #119 so I can then finish #114 and #112.

[jeipollack]

okay, I see it's cumbersome. I will try to have a look, too.

[jeipollack]

Actually I don't see this message that pytest-cases is not compatible with pytest. And the idea of you checking the distributions is not necessarily to identify a solution but to understand what the problem is caused by and then we discuss collectively solutions for which you're welcome to propose a solution if you have one.

[nadamoukaddem]

Yes, maybe it's just the fixture that is not compatible.(link). Also, in this link, I didn't see version 8 of pytest, and the latest release of pytest-black was in October 2020, so it's been quite a while.

[nadamoukaddem]

The plugins pytest-cases, emoji, and xdist have been updated with their codebases. However, pytest-black has a pre-release label for the latest version (and all previous versions), while the raises plugin and pytest-cov have tags but no formal releases.

[jeipollack]

Thank you for your updates.

I had a look myself and the failure is due to the last release of pytest-black no longer being compatible with pytest 8.x. Additionally, it's concerning to note that the plugin is no longer maintained, which may pose further challenges for us in the future. Regarding fixture incompatibility, this is not the cause of the issue as the CI tests for 3.9 and 3.10 passed successfully.

I discussed this matter with Sam, and it's clear that we need to address this issue to ensure the stability and compatibility of our codebase.

At the next meeting, we can discuss the options below in our plan of going forward:

Temporary Workaround: Bypass the pytest-black check in our CI workflow or use an older version of pytest like 7.4.4. This will prevent the failures from blocking our testing process while we work on a more permanent solution.

Long-term Solution: We'll need to explore alternatives to pytest-black that are compatible with pytest 8.x and actively maintained. This may involve finding a replacement plugin or possibly contributing to pytest-black's development ourselves if feasible.