Pluggable browser providers - #385
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #385 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 7 8 +1
Lines 710 735 +25
=========================================
+ Hits 710 735 +25 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| ## The `BrowserProvider` interface | ||
|
|
||
| A provider is a class that accepts a configuration object in its constructor and | ||
| implements the following asynchronous lifecycle. You can subclass |
There was a problem hiding this comment.
I think protocol classes are not meant to be subclassed. And I was wrong. Subclassing is OK, and even recommended by some.
| ```python | ||
| # settings | ||
| PLAYWRIGHT_BROWSER_PROVIDER = "myproject.providers.PatchrightBrowserProvider" | ||
| PLAYWRIGHT_BROWSER_TYPE = "chromium" |
There was a problem hiding this comment.
I wonder if we could make it so that a provider can make this setting unnecessary.
There was a problem hiding this comment.
I don't think so, unfortunately. Browser instances expose this via browser.browser_type.name, but persistent contexts do not have a linked browser type. The browser name is used internally in the handler, and there wouldn't be a way to retrieve it in persistent contexts.
An alternative would be to require browser providers to declare a browser name attribute, but that would be basically the same as the current setting.
Co-authored-by: Adrian <adrian@zyte.com>
|
About 145360d, mind that the same happens at least in 1 more place. |
2 participants
Strategy pattern implementation to allow integration of compatible third-party projects without having to touch the handler internals. Adds a
PLAYWRIGHT_BROWSER_PROVIDERsetting and aprovidermodule with the default implementation (PlaywrightBrowserProvider).Related to #326 and #345, closes #384,