dash
dash copied to clipboard
enable changing of url relative to selenium
Currently, there is no way to use Selenium grid in a separate container/pod because BaseDashRunner assumes that the Dash server will be on localhost relative to the Selenium host. In other words, for a setup where the Dash app lives in container1 and Selenium lives in container 2, pytest can be invoked with pytest --remote-url http://container2:4444 but it will fail because Selenium in container2 will attempt to connect to localhost rather than container1 (since url@BaseDashRunner is hardcoded to localhost).
This MR adds host and scheme attributes to BaseDashRunner so that the user can better specify the location of the app relative to Selenium.
Thanks @danielklim - just to be clear, can you show an example of using these new attributes?
Also please switch to double quotes to appease the linter (or install black==19.10b0 and call npm run format but I believe it's just the quotes) and then merge the new tip of dev to fix the cryptography problem blocking the Py3.6 build. Then this should be good to go!
@alexcjohnson dev merged in and here is an explanation/demo of the issue
Let me know if you need anything else -- thanks!
@danielklim thanks for the great demo, and apologies for being slow to get back to this.
Does the demo represent how you would use this in practice? I'm glad that with this update the necessary functionality exists, but it bothers me that you need to synchronize code in the calling function (pytest --remote-url http://selenium:4444) with code inside the test case (dash_duo.server.host = 'dash'). That means you can no longer run these tests locally, just calling pytest, you're locked into using the selenium grid. Could we get around that with another command line option like --dash-url http://dash:8050 or --dash-host dash so the test case itself need not know where it's being run?
@alexcjohnson I think it's a great idea to add command line arguments as you suggested to avoid having to hardcode the remote url!
I'm a bit slammed with other work right now so can't really do it myself but it should be a pretty quick fix for anyone who is actively working on the code base; or you could just merge in my original MR since it does technically do what it's supposed to and create a future todo for the cmd line args.
Hi @T4rk1n - is this one still relevant or has it gone stale?
thanks @T4rk1n - I'll add it to the pile for the next cycle.
Glad to see this getting merged in!