Skip to content

plugin: pluginargument decorator #4747

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

Merged
merged 4 commits into from
Aug 19, 2022

Conversation

bastimeyer
Copy link
Member

This PR changes the plugin argument definitions from

from streamlink.plugin import Plugin, PluginArgument, PluginArguments

@pluginmatcher(...)
class Foo(Plugin):
    arguments = PluginArguments(
        PluginArgument(...),
        PluginArgument(...),
        PluginArgument(...),
    )

to

from streamlink.plugin import Plugin, pluginargument, pluginmatcher

@pluginmatcher(...)
@pluginargument(...)
@pluginargument(...)
@pluginargument(...)
class Foo(Plugin):
    ...

As mentioned in #4741 (comment), having plugin arguments definied in a similar declarative way as the URL matchers makes it much more consistent and easier to read. The previous definitions were all rather messy.

This also simplifies the parsing of each plugin module's AST via the plugins extension of the docs and the planned URL-cache pre-build step (#4741).

These changes are fully backwards compatible and custom plugins don't need to change anything. I didn't add tests for the old definition style though, but that's not important.

The docs and man page should stay the same, except for the changes of the help texts and some argument rearrangements.

I also fixed some of the help texts, but didn't do a very careful job here. There's still lots of room for improvement. Since this requires testing plugins in some cases, I couldn't be bothered, so I only fixed the obvious stuff.

As usual, review the commits separately.

Don't let plugins with no arguments share a common Arguments instance
Use the same signature as the Argument class and initialize the plugin's
`arguments` class attribute if it's `None`.

Defining plugin arguments the old way is still supported and unchanged.
And clean up some plugin arguments:
- Use consistent keyword order
- Fix (most) help texts
- Fix string indentation and quotation
- Logically rearrange some plugin arguments
@bastimeyer bastimeyer force-pushed the plugin/pluginargument branch from 800c028 to c72feee Compare August 18, 2022 23:34
@bastimeyer
Copy link
Member Author

@gravyboat gravyboat merged commit b6166ad into streamlink:master Aug 19, 2022
@bastimeyer bastimeyer deleted the plugin/pluginargument branch August 19, 2022 05:25
Billy2011 added a commit to Billy2011/streamlink-27 that referenced this pull request Aug 19, 2022
Don't let plugins with no arguments share a common Arguments instance
Billy2011 added a commit to Billy2011/streamlink-27 that referenced this pull request Aug 28, 2022
Use the same signature as the Argument class and initialize the plugin's
`arguments` class attribute if it's `None`.

Defining plugin arguments the old way is still supported and unchanged.
Billy2011 added a commit to Billy2011/streamlink-27 that referenced this pull request Aug 28, 2022
And clean up some plugin arguments:
- Use consistent keyword order
- Fix (most) help texts
- Fix string indentation and quotation
- Logically rearrange some plugin arguments
Billy2011 added a commit to Billy2011/streamlink-27 that referenced this pull request Sep 3, 2022
Don't let plugins with no arguments share a common Arguments instance
Billy2011 added a commit to Billy2011/streamlink-27 that referenced this pull request Sep 3, 2022
Use the same signature as the Argument class and initialize the plugin's
`arguments` class attribute if it's `None`.

Defining plugin arguments the old way is still supported and unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants