Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[🚀 Feature]: Publish Selenium Manager as a native shared library #15355

Open
nvborisenko opened this issue Mar 1, 2025 · 8 comments
Open

Comments

@nvborisenko
Copy link
Member

nvborisenko commented Mar 1, 2025

Feature and motivation

Selenium Manager is a tool, executable binary. Meaning that if I want to use it programmatically I should invoke it as new OS process.

But it can be simplified:

  • Share SM as native library (very easy to do!)
  • Expose rust extern function (easy to do)

Then I will be able to use Selenium Manager functionality without a hell of "OS process communication". I am from .NET world.

Usage example

  • In .NET it will be 20 lines of code instead of 200 (including realtime logging from SM!)
  • More performant! (and memory 50KB vs 200B)
  • Lightweight footprint for end users: like if my application is targeted to MacOS, then only MacOS native SM will be a part of my application (at this time all 3 targets)
  • I will be able to publish my application as single file. Currently SM binaries are placed besides of my application, I don't want to see SM.
  • Bindings will not include executable binaries which leads to be more friendly with Antiviruses.
Copy link

github-actions bot commented Mar 1, 2025

@nvborisenko, thank you for creating this issue. We will troubleshoot it as soon as we can.


Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

@titusfortner
Copy link
Member

Here's the analysis I'm looking at: https://chatgpt.com/share/67c77ba9-1d58-800a-8480-c7406f98e9b5

My takeaway is that it isn't worth having multiple implementations, but we should discuss it more.

@cgoldberg
Copy link
Contributor

No comment on the PR or decision, but I just wanna say that ChatGPT analysis is freakin incredible... like... wow 🤯

I'm still adjusting to how impressive some AI can be, and that really hit me. Scary.

@titusfortner
Copy link
Member

Yeah, I still have to go back and forth with it a bit to make sure I'm actually asking the right questions, but deep research is a game changer

@shs96c
Copy link
Member

shs96c commented Mar 5, 2025

I read the analysis, and it boils down to:

  1. Language bindings need to include a native component
  2. Linking against a DLL may cause the runtime to crash
  3. In all cases, memory usage will reduce
  4. There should be less code in the language bindings since more can be delegated to the rust code
  5. In some cases deployment may be simpler (the openssl issue mentioned in the analysis)

Taking each of these in turn:

  1. We already need to do this for the Selenium Manager binary itself. A DLL isn't a problem
  2. We've faced this before (the original input library we used to use on Linux and Windows), and it's not a big issue
  3. This is a Good Thing :)
  4. This is likely true, and making things simpler is good. Replacing congruent code with a single implementation is a win.
  5. This is a Good Thing too (I can imagine that code-signing on macOS may be an issue at some point for a standalone binary)

Given that the proposal is to add a new mechanism to call Selenium Manager, rather than to remove the binary, and given that there are some nice benefits we could get from this, it seems like moving forwards with this (perhaps only in the .Net binary to start with) is a reasonable thing to do.

BTW, another benefit about allowing Selenium Manager to be linked as a library is becomes possible to embed it elsewhere, which may expand its reach.

@titusfortner
Copy link
Member

@shs96c where else would it be embedded?

I was thinking that if the bindings are the only consumer, then some of the input/output can be simplified compared to the CLI commands, but I want to make sure I understand the other use cases.

@nvborisenko
Copy link
Member Author

Probably I am not good engineer, but do you feel the difference between "start OS process" and "use library"?

@titusfortner
Copy link
Member

The more I think about it, the more potential I think it has to simplify things in the long run when considering the bindings specifically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants