Migrate importlib.resources into a package

[jaraco]

BPO	46118
Nosy	@jaraco, @tirkarthi, @FFY00
PRs	bpo-46118: Move importlib.resources to its own package. #30176 bpo-46118: Make sure importlib.resources is included. #30311

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2022-01-01.19:16:30.847>
created_at = <Date 2021-12-17.20:54:28.125>
labels = ['3.11']
title = 'Migrate importlib.resources into a package'
updated_at = <Date 2022-01-01.19:16:30.847>
user = 'https://github.com/jaraco'

bugs.python.org fields:

activity = <Date 2022-01-01.19:16:30.847>
actor = 'jaraco'
assignee = 'none'
closed = True
closed_date = <Date 2022-01-01.19:16:30.847>
closer = 'jaraco'
components = []
creation = <Date 2021-12-17.20:54:28.125>
creator = 'jaraco'
dependencies = []
files = []
hgrepos = []
issue_num = 46118
keywords = ['patch']
message_count = 8.0
messages = ['408815', '408818', '408916', '409398', '409400', '409401', '409402', '409404']
nosy_count = 3.0
nosy_names = ['jaraco', 'xtreak', 'FFY00']
pr_nums = ['30176', '30311']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue46118'
versions = ['Python 3.11']

[jaraco]

The importlib.resources module has several modules on which it relies (_adapters, _legacy, simple) and some classes in other modules shared by other parts of importlib (namely abc).

Because these implementations overlap, it adds difficulty in maintaining the importlib_resources backport, which must maintain these modules but keep them separate from the unrelated functionality in other parts of importlib.

In an earlier refactoring, importlib.metadata was refactored into its own package (#25565). This refactoring had benefits of making it clearer which functionality of importlib was related to metadata and which was not.

I'd like to do the same for importlib.resources.

The main complicate

[jaraco]

Compatibility considerations:

• importlib.readers and importlib.simple are public, so probably need aliases.
• Same abc classes.

Should we embark on an effort to migrate users to the new names in importlib.resources, or simply leave the importlib.{mod} names as preferred? My instinct is to do the former, mainly because then the names would be congruent between importlib.resources and importlib_resources. But I'm also reluctant to introduce a deprecation (even deferred) comparable to what happened with collections.abc.

[jaraco]

I recently noticed that some docs already refer to importlib.resources.abc even though it doesn't currently exist (https://github.com/python/cpython/blame/main/Doc/library/importlib.rst#L948). That finding leads me to adjust my expectation that perhaps exposing those classes from that module would be preferable (since that was the expectation from the start).

[jaraco]

New changeset e712a5b by Jason R. Coombs in branch 'main':
bpo-46118: Move importlib.resources to its own package. (bpo-30176)
e712a5b

[jaraco]

Installed buildbots are failing (like this one: https://buildbot.python.org/all/#/builders/350/builds/1164). I'm going to see if it's a simple fix like updating the makefile or if a rollback is called for.

[jaraco]

Looks like I encountered the same foot gun when originally introducing the importlib.metadata package (bpo-34632).

[jaraco]

And the underlying cause is reported in bpo-37043.

[jaraco]

New changeset 35628e4 by Jason R. Coombs in branch 'main':
bpo-46118: Make sure importlib.resources is included. (GH-30311)
35628e4