session: re-organize session and http_session modules #5807
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ref #4741
Part 2/x
This fixes some long overdue issues with the
sessionandhttp_sessionmodules, and it's also a necessary preparation for the lazy plugins loader implementation.Motivation
The
plugin.api.http_sessionmodule is not actually part of the "plugin API". It is one of the main dependencies of thesessionmodule, which means it doesn't belong into theplugin.apipackage. TheHTTPSessionis also (obviously) used in many other places, like in the stream implementations for example, and it's always referenced using theStreamlinksession object.The
http_sessionmodule was added ~10 years ago during the Livestreamer era via 936e66d, so plugins could share arequests.Sessionobject between HTTP requests, which were previously done directly viarequests(with an optional session passed to each request).Module re-organization
The following commits re-organize the module structure (see the commit message for more details):
streamlink.sessioninto a sub-package, with theStreamlinkclass being defined in thestreamlink.session.sessionmodule, but re-exported instreamlink.sessionStreamlinkOptionssubclass ofOptionsto thestreamlink.session.optionsmodule, so it doesn't bloat up thesessionmodule. This also moves all the option definitions and docs into that module, which is much better.HTTPSessionsubclass ofrequests.Sessionto thestreamlink.session.httpmodule.streamlink.plugin.api.http_sessionmodule for compatibility reasons.Before:
https://github.com/streamlink/streamlink/tree/6.5.1/src/streamlink
After:
https://github.com/bastimeyer/streamlink/tree/836e30029d36ee27ad13ba511127c24c511cce44/src/streamlink
Future benefits
This allows extending the
streamlink.sessionsub-package with more modules, e.g. for the lazy plugins loader, which will move plugins loading and resolving logic from the mainStreamlinksession class.Notes
streamlink.plugin.api.useragentsunfortunately is still a dependency ofstreamlink.session.http. I'm not sure if changing this is worth it, because if we'd move that module, then a compatibility module with re-exports would need to be added anyway. This could maybe be done in the future. It's not too important though.TheEverything's compatible, with deprecation warnings when importingHTTPSessionclass was never meant to be imported by any plugin, so those references have been removed fromstreamlink.plugin.api(and not been added back, unlike theHTTPAdapterclasses). Other than that, everything should be compatible. I don't consider this a breaking change.plugin.api.HTTPSessionorplugin.api.http_session.{HTTPSession,TLSNoDHAdapter,TLSSecLevel1Adapter}.TheTLSNoDHAdapterandTLSSecLevel1Adapterclasses are currently re-exported instreamlink.session, becausestreamlink.session.httpis considered a private module now. I'm not super happy with this, because it's HTTPSession related. I don't really mind plugins importing from thehttpmodule though. There's only one plugin which imports one of these custom adapters, and that's FilmOn. I'll have to think about it.