Are there any plans to port puppeteer to Python?

[michaelfward]

No description provided.

[ebidel]

No plans for the foreseeable future. We want to nail the Node experience first and foster a JS API that works really well with the DevTools protocol.

FWIW, there are several community projects that allow you to work with the protocol using Python:
https://github.com/ChromeDevTools/awesome-chrome-devtools#protocol-driver-libraries-in-various-languages

[michaelfward]

Thanks! I did see some good Python modules in there.

I'm new to open source, so I apologize for this potentially unnecessary question: is it "not okay" to independently start an open source port (assuming that further reading of the Python implementations don't have all the functionality I need), and attempt to keep it in line with the Puppeteer API?

In my day job, there are immediately tangible benefits to using Puppeteer over PhantomJS, and maintaining the project may end up being more efficient. However, I don't want to step on anyone's toes!

[paulirish]

it's totally OK to write a python library that exposes the puppeteer API in python. It would make sense to depend on chromote or pychromedevtools for interfacing with the protocol.

go for it!

[ebidel]

is it "not okay" to independently start an open source port

Nothing stopping you from starting something new and basing the API off another project. In fact, Puppeteer's API was inspired by projects like NightmareJS, PhantomJS, and others.

keep it in line with the Puppeteer API

I think is the challenge right now. Puppeteer's API will most certainly evolve as we work towards a 1.0. IMO, it may be too soon to try to port code. I'd take a look at those other projects though.

Another thing you could try is calling into Node/puppeteer from Python. Obviously wouldn't be ideal if you're trying to avoid Node altogether :)

[zyv]

https://pypi.python.org/pypi/pyppeteer ;-) FYI

[michaelfward]

@zyv Unfortunately (and I can't emphasize "unfortunately" enough), the module must run on Python 2.7 with no external dependencies outside websocket-client (or another comporable websocket package) and what the standard library provides for my use case.

So, again unfortunately, that completely rules out Python 3.x+, asyncio, gevent, etc.

I have an implementation that's completely usable in production for my own use cases at the moment, but it's pretty big, and there are some latent synchronization issues that I haven't resolved yet (mostly because they only come up during super high traffic periods, like when screencasting etc. none of the triggers are in any way required for my use case, so I haven't had the motivation to resolve them yet), which is preventing me from publishing. I can be a bit of a perfectionist :P

[michaelfward]

FWIW: If anyone else has an interest in the module, please let me know. I've been under the impression that the constraints (Python 2.7 + no external dependencies) and use case (web scraping & page automation) are so narrow that it wasn't worth publishing, but I will if I learn otherwise.

[hayd]

@michaelfward I'd be interested to see that! For us I don't think the py3 + deps is necessarily an issue but would be interested to see your approach!

[madisvain]

@michaelfward this would be of interest to us as well as sadly we still require python2 support

[slothyrulez]

@madisvain @michaelfward If chrome / chromium is not a requirement > https://marionette-client.readthedocs.io/en/master/