Open DetachHead opened 1 month ago
Isn't this the case for this package? The whole purpose was to bundle the binaries into a python package so you can install the package and also have chromedriver installed installed. https://pypi.org/project/chromedriver-py/#files have a look here, this is the reason why the package is 43MB big :)
it's good that the binary is included with the wheel, i didn't realize that because i was looking in .venv/scripts
(or .venv/bin
if using linux/macos). however it would be better if there was also a chromedriver
script in that scripts folder, because that way the directory containing it will already be in the path when the venv is activated.
for example, you could have a wrapper script that looks something like this:
# ./chromedriver_py/run.py
from subprocess import run
from chromedriver_py import _get_filename
def main():
run([_get_filename(), *sys.argv[1:]])
and in pyproject.toml
:
[project.scripts]
chromedriver = "chromedriver_py.run:main"
more info here. (i can see this project does not use pyproject.toml
, so i'm not sure what the setup.py
equivalent is)
the benefit of doing this is that all the user needs to do is pip install chromedriver-py
then they should be able to use selenium without any additional steps, because chromedriver
will already be in their PATH
by default
@DetachHead Thanks for the clarification! I already got an Issue that titles "add chromedriver to PATH" since i got that idea for some time now :) Thanks for the examples, these will help me a lot! I try to find some spare time to implement that :)
is it #8? should we close this issue and re-open that one?
Ouh i closed it.. nope lets keep this one open here :)
Would it be better to copy the real executable into the scripts folder, rather than create a new executable that runs python, runs a script that then runs chromedriver?
if we add:
setup(
...
scripts=["binaries/chromedriver"] # etc
)
the binaries will be included directly
I can add this to scripts, this should do the trick BUT the problem would be that you have multiple chromedriver binaries in your path then. and depending on your OS you have to refer to a specific one. would that already be fine for your needs? I tried building one wheel for easy distro but this is not documented at all on the internet somehow ..
the problem would be that you have multiple chromedriver binaries in your path then.
is this because all of the chromedrivers are included? specifying by name would work, but wouldn't really improve my specific usage of binary_path
, perhaps #7 can be addressed simultaneously?
I tried building one wheel for easy distro but this is not documented at all on the internet somehow ..
yeah, python build sucks. have you tried python setup.py bdist_wheel
?
Yes #7 has to be addressed before this change.
The Problem with platform specific wheels is that this is the only docu: https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#platform-wheels
It also says that if the builder detects that you have just pure python code, it will not build a specific version for each distro ... and this is what happens when i build the wheel aswell.
Maybe use PDM instead?
it would be great if this package worked the same way as nodejs-wheel, where the binary is bundled with the wheel and exposed as a script. this would mean that
pip install chromedriver-py
would be all the user needs to do, without having to manually run any additional scripts to actually install chromedriver.