Repository navigation
Migrate importlib.resources into a package #90276
Description
| BPO | 46118 |
|---|---|
| Nosy | @jaraco, @tirkarthi, @FFY00 |
| PRs |
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']
Activity
jaraco commentedon Dec 17, 2021
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_resourcesbackport, which must maintain these modules but keep them separate from the unrelated functionality in other parts of importlib.In an earlier refactoring,
importlib.metadatawas 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 commentedon Dec 17, 2021
Compatibility considerations:
Should we embark on an effort to migrate users to the new names in
importlib.resources, or simply leave theimportlib.{mod}names as preferred? My instinct is to do the former, mainly because then the names would be congruent betweenimportlib.resourcesandimportlib_resources. But I'm also reluctant to introduce a deprecation (even deferred) comparable to what happened withcollections.abc.jaraco commentedon Dec 19, 2021
I recently noticed that some docs already refer to
importlib.resources.abceven 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 commentedon Dec 31, 2021
New changeset e712a5b by Jason R. Coombs in branch 'main':
bpo-46118: Move importlib.resources to its own package. (bpo-30176)
e712a5b
jaraco commentedon Dec 31, 2021
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 commentedon Dec 31, 2021
Looks like I encountered the same foot gun when originally introducing the importlib.metadata package (bpo-34632).
jaraco commentedon Dec 31, 2021
And the underlying cause is reported in bpo-37043.
jaraco commentedon Dec 31, 2021
New changeset 35628e4 by Jason R. Coombs in branch 'main':
bpo-46118: Make sure importlib.resources is included. (GH-30311)
35628e4