Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate importlib.resources into a package #90276

Closed
jaraco opened this issue Dec 17, 2021 · 8 comments
Closed

Migrate importlib.resources into a package #90276

jaraco opened this issue Dec 17, 2021 · 8 comments
Labels
3.11 only security fixes

Comments

@jaraco
Copy link
Member

jaraco commented Dec 17, 2021

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
    Copy link
    Member Author

    jaraco commented 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_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 jaraco added 3.11 only security fixes labels Dec 17, 2021
    @jaraco
    Copy link
    Member Author

    jaraco commented Dec 17, 2021

    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
    Copy link
    Member Author

    jaraco commented Dec 19, 2021

    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
    Copy link
    Member Author

    jaraco commented 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 jaraco closed this as completed Dec 31, 2021
    @jaraco jaraco closed this as completed Dec 31, 2021
    @jaraco
    Copy link
    Member Author

    jaraco commented 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 jaraco reopened this Dec 31, 2021
    @jaraco jaraco reopened this Dec 31, 2021
    @jaraco
    Copy link
    Member Author

    jaraco commented Dec 31, 2021

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

    @jaraco
    Copy link
    Member Author

    jaraco commented Dec 31, 2021

    And the underlying cause is reported in bpo-37043.

    @jaraco
    Copy link
    Member Author

    jaraco commented Dec 31, 2021

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

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.11 only security fixes
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant