cli: remove the https-proxy option in favour of a single http-proxy option

[beardypig]

I have made the --https-proxy command line argument in to an alias for --http-proxy and suppressed the help output for --https-proxy. https-proxy has been removed from the get/set_option methods, and it will have no effect if set. An info log level message is auto emitted if the --https-proxy option is used.

resolves #4094

[bastimeyer]

The question is, do we want to deprecate the https-proxy option/argument, or do we want to remove it?

The next release will be a major version bump, so removing it can be an option. If we deprecate the option, then we should keep fallback behavior in both streamlink and streamlink_cli. The docs nowadays also have a deprecations page, so newly deprecated stuff should be added there.

You have currently removed logic from streamlink but kept fallback behavior in streamlink_cli, which means the --https-proxy CLI argument will get translated, but session.set_option("https-proxy", value) will not (test_https_proxy_no_effect).

[beardypig]

Maybe it is better to remove https-proxy completely, but where should it be documented that the option has been removed?
Should the argument be left as SUPPRESS for now and then removed when the next version is release, as not to break the nightlies right away?

[bastimeyer]

I think it'd be better to deprecate the option/argument first. Then we don't introduce a disruptive sudden change.

Just suppress the CLI argument, keep the logic in streamlink_cli (which sets the https-proxy option on the session) and then add a deprecation message to Session.set_option when https-proxy gets set, so that both cases are covered, the CLI and the Session API.

We can then remove it with the next major bump (probably when py36 support gets removed, which sees its EoL at the end of this year).

[bastimeyer]

We should be very clear that --http-proxy affects HTTP/HTTPS requests + WebSocket connections (for all kinds of supported proxies), and that it's not about proxies via HTTP/HTTPS.

The CLI docs, the --http-proxy argument help text, the http-proxy session option description and deprecation text all differ and are a bit vague, which is not good. This makes it confusing for the end users, who can misinterpret the option.

[bastimeyer]

Thanks. I think this is looking good now. 👍
Let's wait a bit for more feedback though, in case we've missed something.

• --http-proxy and --https-proxy CLI args now achieve the same thing
• Same thing for when using the Session API directly
• Setting the https-proxy option prints a deprecation message
• --https-proxy doesn't get listed in the docs / man page / help output anymore
• Docs are in good shape

[gravyboat]

Looks good to me.