DeprecationWarning: path is deprecated. Use files() instead.

[user202729]

https://github.com/pyutils/line_profiler/blob/main/line_profiler/toml_config.py#L111

currently the code uses path(), but I get a warning message

DeprecationWarning: path is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy for migration advice.

[TTsangSC]

Huh, this is a curious edge case and the rabbit hole runs deep.

TLDR

We don't do anything directly with importlib_resources and some code (that we have no control over) probably substituted importlib.resources with it, causing the issue.

There is no one-size-fits-all solution because of changes between importlib_resources versions (yours probably being outdated; see "Possible fixes and ramifications"), and trying to fix it (esp. testing the fix) may be rather involved.

What likely happened

As it is now in the codebase we don't ever interact with importlib_resources (the backport) but only importlib.resources that (C)Python ships with – and path() has never been deprecated there.

What is happening with your case is probably that you (or one of your dependencies) have code somewhere which did stuff like

try:
    import importlib_resources as _ir
except ImportError:
    import importlib.resources
else:
    import sys
    import importlib
    importlib.resources = sys.modules['importlib.resources'] = _ir
    del _ir

or more convoluted buffoonery with the import system.

Possible fixes and ramifications

I'm not terribly keen on migrating to importlib.resources.files() because:

• Python 3.8 (the lowest we support) doesn't have files(), and thus we'll have to add a dependency to importlib_resources, which we otherwise have no reasons to; and
• Semantically we're working with a single file, and IMO it doesn't make sense to do something like path, = files() while path() is just there. EDIT: never mind, on closer inspection this isn't how files() work; see also the implemented fix at FIX: DeprecationWarning emitted by how line_profiler.toml_config uses importlib.resources #406

That said:

• importlib_resources.path() which emits the warning you saw have been removed in 6.0.0;
• And yet, path() has been reinstated in 6.4.0 by just importing it from importlib.resources.

All these mean that while a simple fix like

with contextlib.ExitStack() as stack:  # Line 111
    stack.enter_context(warnings.catch_warnings())
    warnings.filterwarnings('ignore', message='.*importlib-resources.*')
    path = stack.enter_context(importlib.resources.path(...))
    ...

would've fixed your edge case (legacy importlib_resources versions), it would be redundant for new-enough versions (because it just uses the stdlib function), and outright error out for the corner cases in between.

Not to mention that testing for it would be cumbersome. E.g. the test would involve:

• Spinning up a dedicated venv,
• Installing tooling thereto which does the importlib_resources switcheroo, and
• Running code there and checking that
  1. The DeprecationWarning (if any) has been suppressed, and
  2. The code works with arbitrary importlib_resources versions.

So, what now?

Honestly IDK what's the best solution here. We could do a compatibility layer which addresses the importlib_resources idiosyncrasies, but that's code and a lot more tests to be added AND MAINTAINED just for a package we shouldn't have anything to do with. But then again I'd imagine there might be isolated use-cases that require this to be fixed, esp. to account for absence of importlib_resources.path() in importlib_resources >= 6, < 6.4.

Any thoughts @Erotemic? EDIT: I've since written #406 which should close this... not sure if this whole thing should've been considered out-of-scope though.

[Erotemic]

From what I understand files tends to be more robust as it will work with zipped packages. In any case, it's quite niche. I'll take a closer look in a few days.

WRT to Python 3.8, I'm open to removing support for it. We probably should also remove 3.9 in the next release as it will be EOL at the end of the month. This also reminds me we still don't have 3.14 wheels published, so I really need to get on that.

[TTsangSC]

The linked PR uses files() + asfile() when available (3.9+) and path() if not, so we should be on the right track.

By "next release" do we mean 501 or 600? If I may, anything lower than a major bump feels a bit off for (declaring) dropping support for a Python version – as overdue as it may be for 3.8.

AFAIK everything from #365 onwards is newer than 500. So we already have a perf fix (#376), two features (#380, #383), and multiple miscellaneous fixes in line. Should be plenty sufficient for a 510 when you have the time – but then again maybe we should take care of #402 now that we have #391, so that the ARM stuff get a more satisfying roundup.

[Erotemic]

The next release for dropping a python version would be a 5.1.0. Dropping old python version support isn't out of the question for a minor version release. Look at numpy for example. 2.3.4 only supports 3.11-3.14, but 2.1 supports 3.10-3.13.

[user202729]

actually importlib.resources.path is deprecated in 3.11: https://docs.python.org/3.11/library/importlib.resources.html#importlib.resources.path

it is somehow un-deprecated in 3.12 https://docs.python.org/3.12/library/importlib.resources.html#importlib.resources.path

[TTsangSC]

Thanks for the context, so that's why there was a corresponding back-and-fro with importlib_resources I suppose. Seems to happen once in a while with importlib stuff, the one time I got (minimally) involved with CPython was noticing a stray DeprecationWarning with SourceLoader in 3.14.0rc2 or something, and they ended up un-deprecating its whole base class (in the code).

EDIT this also means that the edge case actually happens in a vanilla environment on a supported Python version (3.11), so yes it most definitely warrants a fix. Please see if #406 fixes your issues.

[JostMigenda]

The un-deprecation of importlib.resources.path is noted in the 3.13 release notes (and apparently, this was backported to 3.12, but not 3.11). Given that it is officially supported again, the deprecation warning in this issue here could probably be suppressed until 3.11 is EoL, without other changes to the code.

If I understand correctly, the key additional change in #406 is to ensure things still work if some third-party code deliberately overwrites importlib.resources with an older version (>=6, <6.4) of importlib_resources? Given that this hasn’t happened in this issue here (and is increasingly unlikely to happen in the future, since importlib_resources 6.4 has been out for >1.5 years), maybe it’s not necessary to guard against that in practice?

[TTsangSC]

Thanks for the addition.

I agree, my initial surmise was wrong and this issue was probably entirely a Python-version related one. In that case older test pipelines must also have triggered the warning (which we might not have taken note of), since we already test every minor version between 3.8 and 3.14 (incl.). Will verify and streamline the PR accordingly.

EDIT yes indeed the DeprecationWarning showed in older pipelines on 3.11 and we just didn't notice. Will fix. Once again, thanks for the heads up.