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

Are there any plans to port puppeteer to Python? #575

Closed
michaelfward opened this issue Aug 28, 2017 · 10 comments
Closed

Are there any plans to port puppeteer to Python? #575

michaelfward opened this issue Aug 28, 2017 · 10 comments

Comments

@michaelfward
Copy link

@michaelfward michaelfward commented Aug 28, 2017

No description provided.

@ebidel

This comment has been minimized.

Copy link
Contributor

@ebidel ebidel commented Aug 28, 2017

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

This comment has been minimized.

Copy link
Author

@michaelfward michaelfward commented Aug 28, 2017

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

This comment has been minimized.

Copy link
Collaborator

@paulirish paulirish commented Aug 28, 2017

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!

@paulirish paulirish closed this Aug 28, 2017
@ebidel

This comment has been minimized.

Copy link
Contributor

@ebidel ebidel commented Aug 28, 2017

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

This comment has been minimized.

Copy link

@zyv zyv commented Nov 6, 2017

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

@michaelfward

This comment has been minimized.

Copy link
Author

@michaelfward michaelfward commented Nov 13, 2017

@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

This comment has been minimized.

Copy link
Author

@michaelfward michaelfward commented Nov 13, 2017

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

This comment has been minimized.

Copy link

@hayd hayd commented Feb 7, 2018

@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

This comment has been minimized.

Copy link

@madisvain madisvain commented Feb 7, 2018

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

@slothyrulez

This comment has been minimized.

Copy link

@slothyrulez slothyrulez commented Apr 4, 2018

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

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

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.