Merge with importlib_resources

[jaraco]

In GitLab by @jaraco on Sep 7, 2018, 13:18

In this comment, @warsaw suggests the project might merge with importlib_resources.

I do have a goal to have this functionality released a couple of weeks before the PyPA summit in late October, so ideally before Oct 1.

So this raises some concerns - can this project release the planned 0.1 and 0.2 releases and consider the merge with importlib_resources later, or do we wish to avoid any releases of this functionality prior to the merge with importlib_resources?

Also, what are the advantages of merging with importlib_resources? My instinct would be not to merge the two projects unless they have significant overlap in implementation.

[jaraco]

In GitLab by @warsaw on Sep 7, 2018, 20:36

The reason why I thought about merging importlib_metadata with _resources is exactly because I suspect a fair bit of implementation overlap, especially in the workarounds for zip importing that we had to add for older Pythons. The other option would be to refactor the commonality into a separate package (but then we have 3 problems :) or making some of the implementation details in _resources semi-public so _metadata can use it, then make _metadata require _resources.

It seems like it's just easier to combine them into a single package and share as much implementation as possible. We'd still expose this as importlib.metadata in Python 3.8, but I'm not sure how we expose _metadata as part of _resources. Right now we import importlib_resources. Do we also want to do import importlib_metadata?

[jaraco]

In GitLab by @jaraco on Sep 8, 2018, 13:57

Right now we import importlib_resources. Do we also want to do import importlib_metadata?

That would be my expectation and preference - that way, a developer can rely on the pattern:

stdlib	Backport package	Backport distro
importilb.resources	importlib_resources	importlib_resources
importlib.metadata	importlib_metadata	importlib_metadata

It forms a nice pattern with least surprise.

refactor the commonality into a separate package

If we think first about the desired interface in Python 3.8, where would that common functionality lie? If it lies in importlib.resources, it seems perfectly reasonable for importlib.metadata and importlib_metadata to rely/depend on importlib[._]resources. If, on the other hand, it makes sense for that common functionality to be present in something like importlib._util or importlib._zip_support, then I'd imagine that common functionality should be supplied by importlib2 (the backport of importlib), and both importlib_metadata and importlib_resources would depend on a new release of that. Yes, that does mean new releases of 3 packages, but I think the health of the ecosystem would be better for it.

That said, since these packages are all about backward compatibility and they'll all be fading into the sunset almost as soon as they're released, I'm happy to be a little sloppy about the backport organization, to the point of allowing copy pasta between the two backports.

[jaraco]

In GitLab by @warsaw on Sep 9, 2018, 17:51

I agree that the mapping from the underscored (backport) name to the dotted (stdlib) name is very useful to preserve.

I'm hesitant to tie the fate of importlib_{resources,metadata} to a third party package we don't control (even though Eric is a great dev! :). Let's see how much mileage we can get out of pushing any commonality into importlib_resources through a semi-private API.

For now, I'll close this issue and we can reopen it again if we change our minds.

[jaraco]

In GitLab by @warsaw on Sep 9, 2018, 17:51

closed