Compatibility with black of the newest version of pytest ?

[LudivineChabaud]

I have been utilizing the path.py library for managing file and directory paths in my Python projects. Recently, I have come across issues when executing tests using the newest versions of pytest.

The specific error encountered is:

ERROR test - pytest.PytestRemovedIn8Warning: The (fspath: py.path.local) argument to BlackItem is deprecated. Please use the (path: ... !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! stopping after 1 failures !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!

This indicates that pytest is phasing out py.path.local in favor of pathlib.Path. However, it is not entirely clear to me if this change necessitates that all path-related operations in my test suite should be converted to use pathlib.

Therefore, my question is: Is migrating to pathlib essential within the pytest testing framework, or is it merely a recommendation?
Additionally, I would like to know if os.path is intended to be compatible with pytest in the future, or if there are any planned changes for this library as well.

[jaraco]

Hey Ludivine. Your question pertains primarily to py.path (part of the py project), which has yet another path manipulation library. Nevertheless, I'm happy to help clarify and see if I can find answers to your questions. First, to summarize the different path manipulation libraries in order of their appearance:

• os.path (1990s), part of the Python standard library. The OG function-based library.
• path (aka Path Pie, historically path.py, 2003), this library, uses a subclass of a (unicode) string for maximum compatibility and extensibility. Attempts to offer compatibility with pathlib.
• py.path (2006), built mainly to support pytest but is now (as you're seeing) deprecated.
• pathlib (2014), also part of the standard library. New in Python 3.x. Because it's part of the standard library, it's the go-to for most new applications, especially if they don't need the extended functionality offered by something like path.

Perhaps you already knew that - but I wanted to share in case someone else reading this is unfamiliar with the landscape.

The error you've encountered is due to py.path is in the pytest-black plugin which is abandoned and unmaintained. There's nothing you can do in your test suite to fix the issue. Whether you use os.path or path or pathlib (all viable options), the plugin itself is already coded to rely on py.path. Your only option is to remove pytest-black or pin to older versions of pytest. Unfortunately, that plugin has been abandoned so long that the issue you're encountering hasn't even been reported. I'd suggest reporting it, but it seems unlikely it's going to be solved in that project.

There does appear to be a fork of pytest-black (https://github.com/insertjokehere/pytest-black-ng) that purports to have been created to continue maintenance, but that project, too, is stale.

My projects also were affected by similar problems, and I decided to abandon black altogether in favor of ruff. Note that ruff does the work of several tools, including linting (like flake8/pylint), sorting imports (like isort), and formatting (like black), so adopting it might be a multi-phase effort (such as in my projects: jaraco/skeleton@d2ec047, jaraco/skeleton#99). The advantage is that you have an actively-maintained, fast, and popular tool that does all the work. I'd recommend it if you have the flexibility to adopt it.

I hope that helps. Let me know if you have any other questions.

[LudivineChabaud]

Thank you for the detailed explanation and guidance. Your insights into the differences between the path libraries and the solution to the pytest-black issue are invaluable. Thank you also for the links and references you shared; they will be very useful for furthering my research. I appreciate the advice on switching to ruff and will consider it moving forward.

I understand that Ruff is "necessary" for replacing the obsolete pytest-black module, but are you suggesting that pathlib is required for migrating from the also obsolete py.path, correct?

Thanks again for your help!