Join GitHub today
Python Integration RFC #2747
referenced this pull request
Mar 5, 2019
Kepler.gl just created a jupyter notebook integration using jupyter's widget api. More details can be found here:
After going back and forth around the 2 approch: a) iframe, b) jupyter widget. I am more inclined to use the widget approach.
You can take a look at the kepler.gl tabbleau widget here
That looks really awesome
FWIW @ajduberstein's deck.gl integration #2750 is also going down the Widget path, we have repeated layer updates working without post message and are experimenting with interactivity (sending onClick and maybe onHover back to Python).
We are also thinking about developing some support for the iframe approach as a quick and easy mechanism for general web app integration (that may be outside the scope of deck.gl) and that will likely reuse iframe / post message opt-in ideas from kepler.
What's the reason behind releasing it as a
Good question. I honestly don't think we have made any firm decision on that but I believe it is discussed in the RFC, at least in spirit: We just want to provide a very minimal basic reference binding with a minimal Python API tightly based on the deck.gl/json module and something small like that can live within the current repo.
Apart from the inconvenience of working with lots of little repos, the key challenge I see here is to keep this integration "alive" for the long term, since the current deck maintainers are mostly non-Python folks. Keeping it in the repo keeps it visible and relevant as we refactor and work on new core releases.
If this feature generates a big volume of issues that could certainly be a reason to split it out, or if doing so is helpful in other ways, but then we could end up with "out of sight, out of mind", and these binding could quickly get rusty....
And even if this feature grows big, it does not automatically mean it should be moved out. For a major example of multiple languages in a single repo, see apache arrow.
They have all their language bindings in a single repo and that enables leveraging e.g. github built-in per-language search filters etc. It works really well at least for my light usage: since I frequently reference e.g. the C++ code to understand things on the JS side better, I personally much prefer this setup to having to clone and sift through multiple repos.