Streamlink: revamp cli params / cli

[cdrage]

Imo, we should revamp the CLI so it's much simpler than livestreamer has. Would be a good opportunity to modernize it and use a CLI library instead of the mess that it is right now.

[gravyboat]

Depending on how we want to handle the CLI library, there's always Click, though the Python 3 implementation has a few issues last time I checked.

[fishscene]

@cdrage @gravyboat I sent an e-mail to cdrage as I don't have @gravyboat's e-mail, but I'd like to get a few of us in a meeting to roadmap streamlink.

This seems more of an enhancement and I think we should get some fixes in first to make a baseline release to break from Livestreamer, revamp the CLI, then move forward from there. But let's discuss!

[gravyboat]

@fishscene If possible I would like to keep as much discussion publicly available as possible (which is not possible unless we maintain some sort of youtube channel and record meetings or something) as I think that's essential to any sort of open source project like this. Then anyone who is interested can contribute to the conversation and is aware of the current discussion.

[scottbernstein-zz]

I have some ideas for CLI changes as well. But I agree -- I think the initial release should maintain 100% compatibility with the livestreamer build so that it will be easy to validate.

There may be an argument for maintaining CLI compatibility into eternity and layering additional CLIs ontop of what's there now.

---

From: Forrest [email protected]
Sent: Monday, September 19, 2016 1:50:31 PM
To: streamlink/streamlink
Subject: Re: [streamlink/streamlink] revamp cli params / cli (#8)

@fishscenehttps://github.com/fishscene If possible I would like to keep as much discussion publicly available as possible (which is not possible unless we maintain some sort of youtube channel and record meetings or something) as I think that's essential to any sort of open source project like this. Then anyone who is interested can contribute to the conversation and is aware of the current discussion.

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/streamlink/streamlink/issues/8#issuecomment-248067701, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AESJ1pbjON1E1kmieb0XPrJBEC9xBPS2ks5qrstngaJpZM4J_tlR.

[sbstp]

Could the setup.py script install two entry points? One named livestreamer that maintains compatibility with livestreamer, and a revamped one named streamlink?

[cdrage]

@sbstp imo, we shouldn't do that as it's near-impossible to merge anything into livestreamer anymore. let's clean this up and create something starting from 0.0.1

[fishscene]

I believe we need to set some goals for Streamlink to see where this fits in with our recent Fork. I e-mailed @cdrage earlier, but lets move the conversation to the public view. :)

My worry is that we might fly in all different directions and it may die. As such, I feel it is important to set some goals we can all get excited to work towards and accomplish.

I'd like to propose the following:
1) Merging fixes for LiveStreamer, making sure they work, then setting that as our "2.0.0" baseline release to indicate a break from livestreamer. (Livestreamer is currently at 1.12.2). We can of course set this to whatever version we want.
2) Re-vamp the command line. I've only used it for Twitch, but some folks have pointed out it isn't pretty. We should probably resolve this before moving on to:
3) Contact the various projects to have Streamlink integrated into releases/build-platforms and work through any issues there.

Items to consider:

• Need to agree on a release numbering system. I've personally been a fan of (YY.MM.DD).
• ASAP Need to fix some application breakage due to near-zero activity in Livestreamer for quite some time.
• Need to have some goals we can get excited about and move towards. :)
• When ready, need to contact various projects that depend on livestreamer and work with integrating streamlink as an actively-maintained project.

Thoughts?

[scottbernstein-zz]

I also think that a quality goal for an initial release would be to move to a modern version of Python -- the current livestreamer is using an outdated Python 2.x version and we should really attempt to move to 3.x.

---

From: fishscene [email protected]
Sent: Monday, September 19, 2016 2:26:19 PM
To: streamlink/streamlink
Cc: scottbernstein; Comment
Subject: Re: [streamlink/streamlink] revamp cli params / cli (#8)

I believe we need to set some goals for Streamlink to see where this fits in with our recent Fork. I e-mailed @cdragehttps://github.com/cdrage earlier, but lets move the conversation to the public view. :)

My worry is that we might fly in all different directions and it may die. As such, I feel it is important to set some goals we can all get excited to work towards and accomplish.

I'd like to propose the following:
1) Merging fixes for LiveStreamer, making sure they work, then setting that as our "2.0.0" baseline release to indicate a break from livestreamer. (Livestreamer is currently at 1.12.2). We can of course set this to whatever version we want.
2) Re-vamp the command line. I've only used it for Twitch, but some folks have pointed out it isn't pretty. We should probably resolve this before moving on to:
3) Contact the various projects to have Streamlink integrated into releases/build-platforms and work through any issues there.

Items to consider:

• Need to agree on a release numbering system. I've personally been a fan of (YY.MM.DD).
• ASAP Need to fix some application breakage due to near-zero activity in Livestreamer for quite some time.
• Need to have some goals we can get excited about and move towards. :)
• When ready, need to contact various projects that depend on livestreamer and work with integrating streamlink as an actively-maintained project.

Thoughts?

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/streamlink/streamlink/issues/8#issuecomment-248078557, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AESJ1vQxMKdEVHjB9da8HePw3SdDJJ-9ks5qrtPLgaJpZM4J_tlR.

[sbstp]

1) I agree, all the compatible pull requests and fixes should be merged here, and we should also let people know that we're trying to get a fork going.

2) I also agree that the command line is unintuitive. I wish we could make the transition as friction less as possible for the users, but I realize that it might not be possible to do so. We could probably provide a quick reference guide to help people transition to the new interface.

3) I think that putting an up to date release on pypi would be a good start, even it's it's an alpha version. It would make it really easy for projects using livestreamer to switch over. It would only require that the package be renamed to streamlink. I'm not familiar with pypi uploading, but we should really have multiple people with push access to pypi, so that the project cannot linger like livestreamer.

And I agree with @scottbernstein. We should focus on Python 3. Most distros have Python 3 installed these days and if it isn't, it's easy to install it. In the case of Windows, downloading Python 2 or 3 doesn't make a difference.

[cdrage]

huge +1 for Python 3 support. Shouldn't be too bad to do.

[scottbernstein-zz]

You will notice that the original developer had made some movement towards Python 3 but ran into some snags. Lots of check-in comments on the original project talk about prepping certain files for Py3, but obviously he gave up on the project in addition to the move to Python 3

---

From: Charlie Drage [email protected]
Sent: Monday, September 19, 2016 3:00:41 PM
To: streamlink/streamlink
Cc: scottbernstein; Mention
Subject: Re: [streamlink/streamlink] revamp cli params / cli (#8)

huge +1 for Python 3 support. Shouldn't be too bad to do.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/streamlink/streamlink/issues/8#issuecomment-248089201, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AESJ1qTdSm8c2xU3yasnK64nB8Js_kcCks5qrtvZgaJpZM4J_tlR.

[fishscene]

Can we push for revamping the CLI after our initial base release?

1) Initial Base Release: Merging fixes for LiveStreamer, making sure they work, then setting that as our "1.13.0" baseline release to indicate a break from livestreamer. (Livestreamer is currently at 1.12.2). We can of course set this to whatever version we want.
Contact release points, such as pypi (https://pypi.python.org/pypi) and work on any integration issues.
Note: We'll want as much compatibility as we can get with Livestreamer. Basically, just updating to the latest bugfixes.

I'm using release numbers _very_ loosely here:
Milestone: Python 3.
Release: 2.0.0
Milestone: Re-vamp command line.
Release: 3.0.0

[scottbernstein-zz]

I'm with @fishscene...to some extent...

I would have voted for Py3 integration for the initial release but I guess I see a point in offering a stable version with all of most current plug-in fixes so that we can point the less savvy userbase to 1.13.0 who can't understand how to update Livestreamer plugin fixes that people have posted on their own.

That's lowest risk and quickest turnaround.

Scott

---

From: fishscene [email protected]
Sent: Monday, September 19, 2016 4:24:21 PM
To: streamlink/streamlink
Cc: scottbernstein; Mention
Subject: Re: [streamlink/streamlink] revamp cli params / cli (#8)

Can we push for revamping the CLI after our initial base release?

1) Initial Base Release: Merging fixes for LiveStreamer, making sure they work, then setting that as our "1.13.0" baseline release to indicate a break from livestreamer. (Livestreamer is currently at 1.12.2). We can of course set this to whatever version we want.
Contact release points, such as pypi (https://pypi.python.org/pypi) and work on any integration issues.
Note: We'll want as much compatibility as we can get with Livestreamer. Basically, just updating to the latest bugfixes.

I'm using release numbers very loosely here:
Milestone: Python 3.
Release: 2.0.0
Milestone: Re-vamp command line.
Release: 3.0.0

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/streamlink/streamlink/issues/8#issuecomment-248114407, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AESJ1maEECKuY1drpEN6r754RQaEXbYfks5qru91gaJpZM4J_tlR.

[LoneFox78]

@cdrage @scottbernstein What are you talking about? Livestreamer works with python 3 just fine at least since version 1.10.2, which was the current one when I switched it from python 2 to python 3 on my own system back in november 2014.

Need to agree on a release numbering system. I've personally been a fan of (YY.MM.DD).

This is bad, because it looks like a snapshot from version control instead of a stable release.
(Heh, I assumed livestreamer used GNU style versioning with odd minor numbers reserved for development versions when I made my rc1. It doesn't, so it should have been 1.13.0 instead of 1.14.0...)

Back on topic, I don't see any reason for big changes in command line handling. There may be some individual switches that could have a short form or something like that, but nothing major. Also, please avoid adding new dependencies for stuff like this!

[cdrage]

@LoneFox78 Shouldn't we start from scratch and clean up the CLI / params / _everything_ instead of using the current code which is a mashup of argparse?

Hate to say it, but I'd rather _break_ backwards compatibility if it means a cleaner CLI / experience.

[cdrage]

Start from scratch at 0.0.1 again until we know that _everything_ is stable and release a version of 1.0.0 of streamlink and be less known as the fork of livestreamer

[gravyboat]

I'm fine with breaking backwards compatibility if we need to, should be easy for most people to update as long as we keep the same functionality on the commands.

[sbstp]

I'd like to get a release out ASAP. Livestreamer's last release is more than a year old. It probably has dozens of broken plugins, including twitch, a very major one. If we can get this out soon, we can get a lot of attention around it. It would be great if someone wrote a blog post explaining the reasons why we forked it and our plans for the future. Once this it out, we can work on upgrading the API.

[lawli3t]

I agree with @cdrage on the topic of breaking backwards compatibility. The CLI was painful to use on a daily basis (which I did for a long time) and the code also seems to need some improvements. Doing that without breaking backwards compatibility is going to get pretty hard I think. Especially when trying to revamp the args.

I could help with getting stuff ready for Python 3, which is definitely the way to go in the future.

[lawli3t]

In other issues we talked about maybe using the click library for the CLI (http://click.pocoo.org/5/). We should discuss the pros and cons and see if someone else has another idea. I would be really interested in a better CLI, so I could take a shot at this - although I have to work on my thesis primarily for the next two weeks at least.

Some questions we need to address:

• Breaking backwards-compatibility yes/no
• do we need to add any new commands?
• which commands should be renamed or get a shortcut?
• will we use a library, if yes - which?

I think Click looks pretty good, and even though its an additional dependency it seems pretty well maintained. I will take a glance at the CLI-params and see what I think about the current options.

[scottbernstein-zz]

Some things I could suggest:

1. Add start time (or "delay start for x seconds")/end time (to automatically cut the stream off at a certain time) parameters
2. Conflate some of the duplicative protocol-dependent parameters (--hds-live-edge/--hls-live-edge, --stream-segment-timeout/--hls-segment-timeout/--hds-segment-timeout, --stream-segment-retries/--hls-segment-retried/--hds-segment-retries) into singular options to simplify (because you can only be using one protocol for one execution of the script) such as --live-edge, --segment-timeout, --segment-retries.
3. This is a big one -- remove the requirement to tell livestreamer what protocol to use (hls/hlsvariant/hds/rtmp/httpstream). We have a few ways to get around this by: 1. guessing based upon the URI being requested (if it ends in m3u8 try HLS first, if that fails, try HLSVARIANT; if it ends in .f4m, try HDS etc). 2. If the user has no idea of the protocol or the the protocol is not clear from the URI provided then we can actually walk through each protocol in order to see if it matches what we are expecting in a response from the server.....It would be a heck of a lot more user friendly this way. Of course we still let the user force a protocol if they want.
4. I also think that the way the CLI accepts cookie and/or http-header info could be friendlier.

---

From: Stefan [email protected]
Sent: Monday, September 26, 2016 5:17:41 PM
To: streamlink/streamlink
Cc: scottbernstein; Mention
Subject: Re: [streamlink/streamlink] revamp cli params / cli (#8)

In other issues we talked about maybe using the click library for the CLI (http://click.pocoo.org/5/). We should discuss the pros and cons and see if someone else has another idea. I would be really interested in a better CLI, so I could take a shot at this - although I have to work on my thesis primarily for the next two weeks at least.

Some questions we need to address:

• Breaking backwards-compatibility yes/no
• do we need to add any new commands?
• which commands should be renamed or get a shortcut?
• will we use a library, if yes - which?

I think Click looks pretty good, and even though its an additional dependency it seems pretty well maintained. I will take a glance at the CLI-params and see what I think about the current options.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/streamlink/streamlink/issues/8#issuecomment-249700329, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AESJ1mCULS8NkdqBznYQ1fSO6dt574Feks5quDZ1gaJpZM4J_tlR.

[lawli3t]

what i forgot to add was the idea of an interactive mode. Basically it should prompt you for the stream link and then lets you choose a quality / player / protocol. That way you can use it without specifically knowing which qualities or protocols are available. Im not sure on how hard this would be to implement thought.

[gravyboat]

@lawli3t I wrote a (very) basic wrapper for powershell that did this: https://github.com/gravyboat/livestreamer-powershell so you could select quality and stream and so forth. I don't think it would be too hard to do, and should probably just prompt with something like --interactive.

[sbstp]

I think the prompt should be automatic. There's a way of detecting if stdout is attached to a terminal. If it is, it should engage interactive mode automatically.

[gravyboat]

@sbstp Agreed. Interactive mode should be the default, but if a string is input it should just start going that way, forgot the quality option? Then the command should ask.

[LEChaney]

Yea the CLI was a pain >< especially when I did my multi-segment with seek fork, I kept having to remember a bunch of arguments that were required (--http... something something) or it just behave like the original. Interactive mode would be good. Probably want to fix all the broken stuff in the current version first though, so we have a stable version to work from as a base. This would probably be version 1.0.0. I vote for using semver versioning syntax.

On the note of backwards compatibility, I think we shouldn't worry about it too much. The way I'd like to see Streamlink go is to become more like a proxy server than it is now. i.e. drop other output transport methods (to the player), like pipes, and just output using the input stream transport method (i.e HTTP, RTMP). Then Streamlink's job would be to act as an accelerating proxy (using multiple segments and buffering ahead and behind). The player end point would be expected to understand the streaming method (i.e. HLS, HTTP Progressive, HDS, RTMP). This is useful because often the transport mechanism contains useful metadata for the player, such as information about timing required for seek.

Also I'm not sure why everyone is requesting Python 3 support... I developed my fork the whole time using Python 3 and never had any problems.... So as far as I can tell it's supported, the travis CI even has builds for Python 3 that are all passing, both in Streamlink and for Livestreamer.

[LoneFox78]

On the note of backwards compatibility, I think we shouldn't worry about it too much. The way I'd like to see Streamlink go is to become more like a proxy server than it is now. i.e. drop other output transport methods (to the player), like pipes, and just output using the input stream transport method (i.e HTTP, RTMP). Then Streamlink's job would be to act as an accelerating proxy (using multiple segments and buffering ahead and behind). The player end point would be expected to understand the streaming method (i.e. HLS, HTTP Progressive, HDS, RTMP). This is useful because often the transport mechanism contains useful metadata for the player, such as information about timing required for seek.

@FurryFur This is a bad idea, because it would seriously limit what streamlink can do. Are you aware that currently libav/ffmpeg-based players don't support even decoding HDS? And there are more exotic things out there that streamlink could support, but players will probably not. The proprietary protocol (ACE-stream or something like that) people are using to stream formula 1 races comes to mind...

Also, I'm reading between the lines that there are several people in this discussion who are coming from Microsoft environment and have no idea how Unix/Linux programs are expected to behave. For those, I recommend reading The Art of Unix Programming. It's not only about Unix, but good software design in general.

[Junior1544]

@LoneFox78 & @FurryFur
For myself, I am a windows person and have been since windows 3,0 (being that i was already building and repairing pc's back then is kinda sad :) ) and have never really got into linux because I had no need or reason to.. I got into this a tiny bit because I use Livestreamer on a raspberry pi project I've been working on with a linux dev and he recommended it, and now we're here...

To my mind, it's a bad idea to be just a proxy because most people out there want to use what ever player they prefer (I'm using omxplayer in my project) and with livestreamer piping the audio/video, it makes it very easy and I don't need to worry about codec or format or anything when I point it at a stream...

Just my thoughts here... (as uninformed as they are)

Thank you to every one (especially those I may disagree with, because you make me really think) for all the work going into this great program!
--James

[martinth]

I also like the piping feature, but for a different reason: I watch a lot of Twitch and for certain things (like bigger Dota2 tournaments) I have the problem that they broadcast on US and SEA timezones. So I sometimes use livestreamer to simply dump the stream to a file and tell VLC to open that file. This way I get an easy timeshifting setup where I can pause my playback to things like housework and then come back later to resume where I left off (and get a free "skip boring things" feature).

Besides this, I have the feeling that this comment track goes in a strange direction: From reworking the CLI to a pretty meta discussion about the general direction (hint, hint: Maybe that should be discussed elsewhere ;) )

To come back to the actual discussion: I also think that the CLI is complicated, sometimes confusing and repetitive. I have the feeling that we could do pretty well with splitting it up into different subcommands like git and similar tools do. This way we could provide a quick way to reach different "modes". I.e:

• streamlink play <url>: current default behaviour
• streamlink save <url>: dump to a file
• streamlink proxy <url>: launch a http server that serves the stream
• streamlink info <url> --json: show information about the stream a JSON

This way we could factor our all common arguments (i.e. outgoing proxy settings, location of config file, this kind of stuff) and have the specific options on the subcommand. I'm not sure how to deal with plugin specific options, thou.

[sbstp]

I really like the subcommand style proposed by @martinth. In my opinion, it's the easiest way of using a command line program and the easiest way of documenting a program. What options can I use with play? `streamlink play --help'. The various options get grouped by what they apply to.

[scottbernstein-zz]

I really like Martin's idea to have a few major "modes". Given those modes we can set all the other more complex parameters accordingly -- so for example our Save mode would default to high amounts of retries and long timeout values because we don't care about real time streaming so much as accuracy of the bitstream.

On Sep 28, 2016, at 4:53 AM, Martin Thurau <[email protected][e-mail]> wrote:

I also like the piping feature, but for a different reason: I watch a lot of Twitch and for certain things (like bigger Dota2 tournaments) I have the problem that they broadcast on US and SEA timezones. So I sometimes use livestreamer to simply dump the stream to a file and tell VLC to open that file. This way I get an easy timeshifting setup where I can pause my playback to things like housework and then come back later to resume where I left off (and get a free "skip boring things" feature).

Besides this, I have the feeling that this comment track goes in a strange direction: From reworking the CLI to a pretty meta discussion about the general direction (hint, hint: Maybe that should be discussed elsewhere ;) )

To come back to the actual discussion: I also think that the CLI is complicated, sometimes confusing and repetitive. I have the feeling that we could do pretty well with splitting it up into different subcommands like git and similar tools do. This way we could provide a quick way to reach different "modes". I.e:

• streamlink play : current default behaviour
• streamlink save : dump to a file
• streamlink proxy : launch a http server that serves the stream
• streamlink info --json: show information about the stream a JSON

This way we could factor our all common arguments (i.e. outgoing proxy settings, location of config file, this kind of stuff) and have the specific options on the subcommand. I'm not sure how to deal with plugin specific options, thou.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/streamlink/streamlink/issues/8#issuecomment-250109791, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AESJ1nA7Mc5t8I9Pto2icDNqtdQmisvwks5quirygaJpZM4J_tlR.

[fishscene]

Not sure if streamlink currently has the ability to output multiple methods at once, but I'd like to propose the following syntax:

streamlink -p,--play (options) # Single output
streamlink -p,--play (options) -s,--save (options) -p,--proxy (options), -i,--info (options) #Multiple outputs.

I'm a fan of piping output from one program to another in Linux (streamlink | (file/program), but I'm unsure how this would work under Windows, but I'd like to see support for piping under Linux.

Thoughts on Syntax?

[cdrage]

I like the format that @martinth has proposed. consistent, easy to learn and straight to the point wieh tll these features.

@martinth do you mind creating a different issue with your proposal and then we can move the discussion there / start getting some code completed? :)

[fishscene]

How would we want to handle (for example) the ability to save while watching?
streamlink play
streamlink save
Or
streamlink play save

Maybe have the option to save a playing stream stuffed into the options, but then again, seems like we would be duplicating top-level options into the sub (options) if I wanted to do 2 or more things at once.

[scottbernstein-zz]

I think that might be too much to ask the program to do at once. I would advocate firing up 2 instances of Streamlink for that purpose.

---

From: fishscene [email protected]
Sent: Wednesday, September 28, 2016 11:28:18 AM
To: streamlink/streamlink
Cc: scottbernstein; Mention
Subject: Re: [streamlink/streamlink] revamp cli params / cli (#8)

How would we want to handle (for example) the ability to save while watching?
streamlink play
streamlink save
Or
streamlink play save

Maybe have the option to save a playing stream stuffed into the options, but then again, seems like we would be duplicating top-level options into the sub (options) if I wanted to do 2 or more things at once.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/streamlink/streamlink/issues/8#issuecomment-250202227, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AESJ1pNMaPzTz3puz8AwHZcjbf58a1fiks5quoeSgaJpZM4J_tlR.

[fishscene]

Okie doke.
I was trying to head off future problems if we decide to do multiple things at once. I also wasn't sure if livestreamer could do multiple things at once (I've never tried or looked into it). I do know Linux scripters and programmers love efficiency, and duplicating bandwidth isn't efficient.

This is my 2 cents, and if it's not a direction we want to consider down the road, then lets go with @martin's syntax.

[sbstp]

If we follow the Unix philosophy, we shouldn't do this. We should let another program do this. We can use the tee command that does exactly this. streamlink stdout <url> <quality> | tee backup.mp4 | mpv which saves the stream to backup.mp4 and pipes the video to the mpv player.

[bastimeyer]

I think that might be too much to ask the program to do at once. I would advocate firing up 2 instances of Streamlink for that purpose.

Terrible idea, because you're downloading the stream twice by doing that...

The previous solution to this was using stdout and piping it into multiple, different processes, but this also meant that the --player-passthrough option could not be used.

streamlink -p,--play (options) # Single output
streamlink -p,--play (options) -s,--save (options) -p,--proxy (options), -i,--info (options) #Multiple outputs.

This looks like a decent idea. Having a _simple_ structure for multiple (inputs/)outputs would be great, like ffmpeg has for instance. But it shouldn't be too complicated to use.

[fishscene]

@bastimeyer @sbstp I like the piping, but wasn't sure how that would work on Windows.
I've used VLC to host multiple outputs and was using that syntax as a basis for my proposal as I'm familiar with it and the same commands work on Windows/Mac/Linux. However, internalizing the multi-output may be out of scope for streamlink.

[sbstp]

There must be an easy way for plugins to define options. The command line should be able to detect these options and list them in the help dialog. streamlink help twitch for instance.

So for instance the twitch plugin could have oauth-token, cookie, and disable-hosting options. In the API, these are set using the plugin.set_option(name, val).`

I see two ways for the CLI to handle plugin specific options. The first one is to use automatic namespacing. Using the twitch example again, its option could be specified using the --twitch- namespace, which is generated automatically using the plugin's name. Example --twitch-disable-hosting. The options are not namespaced in the API, since you know which plugin you are working with.

The second option would be to not have namespacing. Since streamlink always uses a single plugin, there's no possibility of a plugin specific option overlapping with one from another plugin. The main issue I see with this approach is that the semantics could get messy if, say, --disable-hosting has a different meaning based on the plugin.

[gravyboat]

I think namespacing is the way to go here. It helps future proof us a lot more and more importantly (to me at least) makes maintenance easier. Then when we're merging some plugin with an option we don't have to review 100 different plugins to make sure there isn't an option conflict.

[martinth]

But, as @sbstp pointed out, there is always just one plugin active at any time, so there is not really the problem of conflict. Besides that: Checking for duplicated options can easily be automated with a unit test.

[jedahan]

It would be nice if for some options, like the oauth tokens, streamlink also looked at environment variables like $STREAMLINK_TWITCH_OAUTH_TOKEN or something similar.

[beardypig]

@jedahan that could be pretty useful ... and not too hard.

[back-to]

closing, doesn't seems like this will be done.

---

if there are other feature discussion in this issue,
they should have there own issue not just randomly posted here.