Add an importlib.resources-based ResourceProtocol

[corranwebster]

Since pkg_resources is deprecated, the envisage.resources system should probably grow an importlib.resources-based equivalent.

The actual code to do this is straightforward.

Possibilities:

• re-write the current PackageResourceProtocol to use importlib.resources (or importlib_resources as needed)
• add a new ImportlibResourcesProtocol and allow the two to live side-by-side
• get rid of ResourceManager completely (it is currently only used by the envisage core to access preferences)
• something else (eg. merging the Envisage resource manager and the Pyface resource manager somehow)

[corranwebster]

Philosophical note on ResourceManager: it is providing something above and beyond what we get from importlib_resources, which is a standard way of specifying something that is to be accessed/loaded later and without any overhead at the time of specification (because it is a string)

But what we might be able to achieve the same effect with a combination of importlib.resources.files, pathlib.Path, (and with a bit of hacking, urllib) by using a (possibly informal) protocol that the resource have an open(mode, ...) method that returns an object can be used as a file-like in a context manager (so with foo_resource.open('rb') as f: ... works).

We could imagine replacing things like "pkgfile:://foo.bar/baz/preferences.ini" with pkgfile("foo.bar/baz/preferences.ini") as a convenience wrapper around files("foo.bar").joinpath("baz/preferences.ini") without too much grief - the delta would be importing the appropriate convenience function in the plugin code.

[rahulporuri]

get rid of ResourceManager completely (it is currently only used by the envisage core to access preferences)

I'm not sure what you mean here. We can't get rid of it completely because external packages contribute preferences as pkgfile:// strings for which we need ResourceManager (or something resembling it). For e.g. mayavi, apptools and an internal project seem to contribute a preferences file as a pkgfile:// string.

re-write the current PackageResourceProtocol to use importlib.resources (or importlib_resources as needed)

This makes the most sense to me. I don't see a good reason why the old and new need to live side-by-side.

something else (eg. merging the Envisage resource manager and the Pyface resource manager somehow)

I'm not sure what this would look like.

[mdickinson]

Since pkg_resources is deprecated

pkg_resources isn't deprecated, as far as I'm aware. It's just that importlib.resources is preferable because it's in the standard library, so avoids an unnecessary dependence on a 3rd party library (setuptools).

[corranwebster]

I'm not sure what you mean here. We can't get rid of it completely because external packages contribute preferences as pkgfile:// strings for which we need ResourceManager (or something resembling it). For e.g. mayavi, apptools and an internal project seem to contribute a preferences file as a pkgfile:// string.

Yes, and specifying the location of preference file via pkgfile:// is the only thing ResourceManager is used for in ETS - nothing else that I can find makes use of it. Admittedly there aren't any other subsystems which are needing the same capability (edit: not true - the image resource system is a similar need), but also it's a bit out-of-sync with the rest of the preferences system, which is assuming files in application home directories and things like that.

What's annoying me a bit is that we have two(!) incompatible-but-similar systems for image resources in Pyface, plus importlib.resources has its Traversible ABC which is very similar in many ways and encapsulates common pieces of the Path and ZipfilePath objects. There's a lot of "more than one way to do it."