Skip to content

plugin: remove Plugin.bind classmethod #4744

@bastimeyer

Description

@bastimeyer

As mentioned in #4358 (comment), the current implementation of the Plugin and Session classes are flawed and cause references of the last initialized Session instance to be kept in memory, meaning that Python's garbage collector can never free this part of memory, including every built-in plugin that's held by the Session's plugins dict (related to #4741).

The Plugin.bind classmethod was implemented in 2e27f21 during the Livestreamer days in order to store the session as a class attribute on each Plugin class and in order to set the plugin's module name when it gets loaded. Later on, the logger class attribute was added, which was then deprecated after the new logging style was implemented in Streamlink. And there's also the _user_input_requester class attribute that was added after the fork.

All of these class attributes are unnecessary except for the session:

  • The module name already exists as a reference in the Plugin base class's constructor via self.__class__.__module__
    edit: It might be necessary to change the output type of Session.resolve_url again, and make it return the module name, so it can be used by streamlink_cli for reading plugin config files and resolving plugin arguments. It currently relies of the module class attribute, and this needs to be removed.
  • The logger is unused except for some methods on the Plugin base class that could easily be updated
  • The _user_input_requester should live on the session instance, not on the Plugin classes

So in order to fix the current implementation, the session instance should be passed to each Plugin's constructor as the first argument instead of just the url string. The other attributes could then be set by the base class's constructor on the class instances if we care about that. As said, they are all unnecessary and could be changed otherwise.

Changing the Plugin class constructor would be a breaking change however. It could temporarily be worked around though by checking the signature of custom plugins and providing a fallback path with a deprecation message that's kept for a bit, similar to the plugin matcher API.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions