Call for Ideas for major refactoring ?

[rasjani]

Back when webdrivermanager started, the initial codebase was not written by me (and still mostly relies on just patching the initial uptream).

Due to this, there are certain things that i do not like about the codebase and i've been toying with the idea to refactor/rewrite things to have more flexible ways to add new features and/or fix existing issues..

Few ideas:

• Each separate webdriver downloader that we have, should be isolated into their own implementations.. Common code should still be inherited from base class (or via mixin's or what ever).
• Have ability to discover what downloader modules are installed in the running system. For example, If someone wants to implement their own version of a thing, say, to support their own filesharing, or implement totally new downloaders, webdrivermanager should be able to pick those up without submitting code and releasing it with "official" webdrivermanger.
• Version checking should be reworked.. For example, there's this pull request: https://github.com/rasjani/webdrivermanager/pull/33 .. Idea is 100% what should be done but that feature should be available for each downloader and the pullrequest in question only implements it for Chrome.
• Then, there has been a question of having the ability to "remove" existing webdriver.. While that is somewhat dubious question by itself, i can see the some features in that that could be beneficial for general usage.

So, people, do you have any other suggestions or features you would like to have in webdrivermanager ?

And would there be people to help with the development efforts ? Worth to say that im not expecting anyone to volunteer, just saying that there's a change to help out if you feel like so.

[osrjv]

I was going to implement browser version checking and downloading specific webdrivers for my own use, but luckily checked the issue tracker first. Probing the browser version can be built on top of webdrivermanager, but I think an extended version of #33 needs to be implemented first for the downloading part. I'm not sure how much time exactly I'd have for helping with development, but it's something I'd like to see realized.

[rasjani]

Both #32 & #22 are really really good ideas .. #22 would essentially "solve" #33 . Most of the time, if you can run the script on environment where you are going to run your automation, its easier to just autodetect what needs to be downloaded.

32 is ofcourse way easier to implement and doing that would serve another use case (keeping up local cache of drivers)..

Main reason why i haven't addressed these before is that i really don't want to write "corner case code" to support every possible webdriver and most of the "design" is that there's official source where to scrape details of how to locate links and metadata (architecture, bitness, os, version). Next problem in the medata: once you know what browser and its version - you need to know what actual driver version you need. I haven't really looked but the official sources i use to scrape for binary locations does not have the kind of data that maps browser version to its webdriver version .. For chrome this is easy to handle as they have versioning scheme where at least major part and parts of minor matches between browser and webdriver but at least in the past, Firefox didn't have similar..

so #22 & #32 are definitely related.

For #22 - i would have merged that already but the pr was chrome only and im firefox guy to the bone. Also, i do have other projects that i do want to test on multiple os's and browsers so having windows & chrome only solution is a bit meh cuz i'd still need to work a big chunk of my test matrix.

I'd settle down for abstracting the browser version detection to parent class and just not having that feature implemented for other browser and implement other supported browsers later on. Same with the #32 - version user provides should be done in single location, not implemented separately =)

[osrjv]

I'm also interested in a bit of a more universal solution, but it unfortunately looks like it'll mean maintaining browser-specific mappings for versions and download locations. The one comforting factor is that in the worst case it can fallback to latest, and then it's on-par with the current implementation.

Luckily with geckodriver the API is a lot more stable compared to chrome/chromium. This is the most official source I found through some quick googling: https://firefox-source-docs.mozilla.org/testing/geckodriver/Support.html