Issue 46118: Migrate importlib.resources into a package
Issue46118
Created on 2021-12-17 20:54 by jaraco, last changed 2022-04-11 14:59 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 30176 | merged | jaraco, 2021-12-17 21:28 | |
| PR 30311 | merged | jaraco, 2021-12-31 02:30 | |
| Messages (8) | |||
|---|---|---|---|
| msg408815 - (view) | Author: Jason R. Coombs (jaraco) * ![]() |
Date: 2021-12-17 20:54 | |
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 (https://github.com/python/cpython/pull/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 |
|||
| msg408818 - (view) | Author: Jason R. Coombs (jaraco) * ![]() |
Date: 2021-12-17 21:37 | |
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`.
|
|||
| msg408916 - (view) | Author: Jason R. Coombs (jaraco) * ![]() |
Date: 2021-12-19 17:21 | |
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). |
|||
| msg409398 - (view) | Author: Jason R. Coombs (jaraco) * ![]() |
Date: 2021-12-31 02:00 | |
New changeset e712a5b277866a71c195f38c1b5d87d9126dba3e by Jason R. Coombs in branch 'main': bpo-46118: Move importlib.resources to its own package. (#30176) https://github.com/python/cpython/commit/e712a5b277866a71c195f38c1b5d87d9126dba3e |
|||
| msg409400 - (view) | Author: Jason R. Coombs (jaraco) * ![]() |
Date: 2021-12-31 02:21 | |
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. |
|||
| msg409401 - (view) | Author: Jason R. Coombs (jaraco) * ![]() |
Date: 2021-12-31 02:38 | |
Looks like I encountered the same foot gun when originally introducing the importlib.metadata package (issue34632). |
|||
| msg409402 - (view) | Author: Jason R. Coombs (jaraco) * ![]() |
Date: 2021-12-31 02:42 | |
And the underlying cause is reported in issue37043. |
|||
| msg409404 - (view) | Author: Jason R. Coombs (jaraco) * ![]() |
Date: 2021-12-31 03:39 | |
New changeset 35628e4cde71e54afe12aea50c74069afe2c3389 by Jason R. Coombs in branch 'main': bpo-46118: Make sure importlib.resources is included. (GH-30311) https://github.com/python/cpython/commit/35628e4cde71e54afe12aea50c74069afe2c3389 |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:53 | admin | set | github: 90276 |
| 2022-01-01 19:16:30 | jaraco | set | status: open -> closed |
| 2021-12-31 03:39:28 | jaraco | set | messages: + msg409404 |
| 2021-12-31 02:42:47 | jaraco | set | messages: + msg409402 |
| 2021-12-31 02:38:25 | jaraco | set | messages:
+ msg409401 stage: patch review -> resolved |
| 2021-12-31 02:30:44 | jaraco | set | stage: resolved -> patch review pull_requests: + pull_request28525 |
| 2021-12-31 02:21:56 | jaraco | set | status: closed -> open messages: + msg409400 |
| 2021-12-31 02:01:07 | jaraco | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
| 2021-12-31 02:00:56 | jaraco | set | messages: + msg409398 |
| 2021-12-24 18:18:26 | FFY00 | set | nosy:
+ FFY00 |
| 2021-12-19 17:21:17 | jaraco | set | messages: + msg408916 |
| 2021-12-18 14:05:23 | xtreak | set | nosy:
+ xtreak |
| 2021-12-17 21:37:19 | jaraco | set | messages: + msg408818 |
| 2021-12-17 21:28:14 | jaraco | set | keywords:
+ patch stage: patch review pull_requests: + pull_request28393 |
| 2021-12-17 20:54:28 | jaraco | create | |
