Add my own silly chrome remote debugging project.

[fake-name]

This is a PR to add the python remote debug protocol wrapper I've been poking about with for the last 8+ months or so.

It's half horrible python AST abuse, but it should allow the protocol wrapper to be regenerated on-the-fly for the active chromium version once https://codereview.chromium.org/2867073006/ (Chromium 60) lands.

At this point, I'm actively using it, and a lot of the higher-level automation is still under development, but as a convenient way to just use chromium in a single-tab manner (multiple tabs are present, very WIP), it's quite nice. I even have docs!

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[fake-name]

I signed it.

[googlebot]

CLAs look good, thanks!

[fake-name]

?

[paulirish]

@fake-name i am not very happy with having 4 python projects in here with fairly similar goals. However, I'm not a python developer, so I'm not in the best place to evaluate the strengths of each project. Can you suggest a project or two that i should remove in exchange for yours?

[fake-name]

Looking at them, I don't see them being that similar at all, really.

• ChromeWhip is the most similar to what my project implements, but they're seeking to re-implement a specific user-facing API (specifically, to be a drop-in replacement for the splash project), rather then just exposing the devtools API itself (which is my goal).
• PyChrome is much lower level, it primarily looks to allow calling arbitrary functions via the websocket transport. It does no checking of argument/function names.
• PyChromeDevTools is very similar to PyChrome.

Realistically, I could probably actually place my project on top of either PyChrome or PyChromeDevTools, using them as the underlying communication transport. However, I've also recently been putting a fair bit of work into the effort of managing execution of the chrome binary, and managing it's life-cycle and proper tear-down. From a quick skim of the other options, none of them do this.

If I were forced to chose, I'd say that PyChrome and PyChromeDevTools very much replicate each-other more then the other projects.

From an organization standpoint, I'd group them into two groups: "Transport", which handle the banal internals of talking to chromium, but don't do things like function name/parameter checking, and "High-Level", which seek to expose the fully structured debugging interface in python. There's another transport python module chrome_remote_shell, which I admit I actually started with as a base.

I'd group PyChrome, PyChromeDevTools, and chrome_remote_shell as "transport" libraries, while ChromeWhip and my own project are "high-level" interface wrappers.

I'm not sure if this helps.

[paulirish]

@fake-name this does help. thanks for that breakdown.

[fake-name]

?