-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Plugin-request rule update discussion #5904
Comments
I don't agree with the removal of category 2 because it will open the flood gates for ridiculous plugin requests again. If people really want those plugins they're free to write them and side load. It's much harder to justify if we don't have an explicit rule for why we don't think the 210th static webcam site of a duck pond should be added for one random person who doesn't even contribute the plugin code. I'd even argue it would be worth updating the seemingly niche plugins no one uses with a warning message in the console saying that unless they comment on a created issue that the plugin will be removed in the next release.
I don't think we should lift this. Otherwise we'll be spammed with people asking for sites that are "TV" stations that have VODs available of previous broadcasts and TV shows again. These plugins aren't worth maintaining especially since many of them can use the more generic methods for directly accessing the URL of the video if that is what people want.
Correct. People were asking for sports TV channels that required login and arguing with us about which rule it broke when no one wanted to do the work for them to add it. I'd be in favor of updating the rule to ban any site which requires login but I know we have a couple plugins like that already and it may be overly harsh. A clarification update would be 👍. Generally I'd be fine with updating the rules for clarity but I don't see a justification for removing any of them. They were all put in place to avoid low effort plugin requests, people arguing with us, seeing the same request over and over (TV VOD sites), etc. |
A lot of the concerns seem to be about people asking for plugins for their favourite site, without having the ability to create them themselves. Can't there be a rule about not asking for sites, unless you can contribute the code yourself in a PR? Maybe the GitHub discussions could be used for requests instead, so the issue tracker is really used for issues and is kept clean? |
Regarding streamlink being LIVE streams oriented (rule 6), it may be worthy to communicate it more prominently (ie at the overview section of the documentation, or the readme at the project home landing), and offer a suggestion for VOD site (ie just point the interested user to yt-dlp) Regarding niche sites, wouldn't be a more proactive approach having a catch all plugin like https://github.com/back-to/generic/ ? (no guarantees thou) |
Maybe it should depend on how much effort it takes to implement the required login. But generally speaking, if someone makes its paid account available for the duration of development, why not? |
I think of it as "audio streaming = video streaming without pictures".
If we can't merge plug-ins for non-video streaming sites, can't we just have a separate "plugin repository for video-platforms" and a "plugin repository for audio-platforms"? |
Let's talk about updating the plugin request/inclusion rules... The last time these rules were updated was in October 2020 and June 2018.
While not being mentioned directly anywhere except in some buried discussions from years ago, there are still plugins on the master branch despite them violating the (current) rules. We never deleted any of those plugins unless they broke and required major changes in order to fix them. Others however were removed with the addition of certain rules.
Current plugin request rules
https://github.com/streamlink/streamlink/blob/6.7.2/CONTRIBUTING.md#plugin-requests
Rule "categories"
There are mainly two different kinds of rules, excluding three of the eleven rules:
The other three rules are this:
Category 1 is pretty much self-explanatory.
Rules of category 2 were added either because of maintenance cost or due to plugins deemed being "not useful" or "too niche" and unnecessarily causing bloat in Streamlink's code base and session memory during runtime. Another reason for adding those rules were people who made daily low-effort requests for sites they didn't even use themselves and probably just found via Google.
Rule change discussions
With the addition of lazy plugin loading in 6.6.0, rules of category 2 could be changed or removed entirely. The only concern would be whether a plugin could be maintained, even if it's "unpopular". This is kind of an important question though, because merging bad plugins doesn't make much sense, and if there's no rule we can point to, then the choice of rejection is arbitrary and always questionable. Ideally we want plugin code to be submitted in a PR instead of plugins to be requested, but allowing plugins of this kind doesn't solve the maintenance issue if nobody is able to fix future issues, even if code is submitted initially. And figuring out which plugins are broken because nobody uses them is also a problem, which means we'd carry around broken plugins for a long time.
Rule 6 may be lifted at some point, but with Streamlink's current VOD support which is pretty bad in terms of viewing and recording, it should stay. The focus is still on live streaming.
No idea about rule 4. AFAICR, this was added because of some sports TV channel requests which required some silly authentication. This rule is not very clear and should be updated or removed.
The text was updated successfully, but these errors were encountered: