Replies: 4 comments 3 replies
-
|
@ilike2burnthing I went down a rabbit hole and converted FlareSolverr over in https://github.com/ppfeister/FlareSolverr/tree/refactor/pkg. Assuming you have Chrome/Chromium and pip install flaresolverr
python -m flaresolverrShould start right up. Much easier to integrate into other projects now. Assuming there's interest, the Dockerfile and similar would just need to be tweaked before bringing any changes forward as a pr. |
Beta Was this translation helpful? Give feedback.
-
|
Some things have been reverted or changed, but basically anything that wasn't a version bump was specific to us - https://github.com/FlareSolverr/FlareSolverr/commits/master/src/undetected_chromedriver |
Beta Was this translation helpful? Give feedback.
-
|
FS's custom UC has been returned as a submodule New rc/demo pushed to pypi under the same name |
Beta Was this translation helpful? Give feedback.
-
|
rc{2..4} pushed with Drission to reflect #1300 (comment) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
FlareSolverr is typically dockerized, but it can be ran as a script if need be. The problem is, this is a pretty poor way to integrate it into other projects.
Just as an example, I'm experimenting with using FlareSolverr as a part of my newer project here. To do so, I have to include FlareSolverr's repository as a submodule and then do some nonsense to treat it as properly importable. Namespace packaging has issues with FlareSolverr as well, so an __init__ file is often needed.
Is there any interest in or opposition to converting FlareSolverr to a properly importable package? This would allow for it to be included in other projects much more easily.
I recently converted Sherlock to a package as well, which allowed for it's easier inclusion in the previously linked project (and others) just the same.
Beta Was this translation helpful? Give feedback.
All reactions