Interest in collaborating with the Buckaroo Table Viewer?

[paddymul]

Hello,

I have been taking a look at Skrub and it's impressive work - well done.

I created Buckaroo to improve the default dataframe viewing experience in Jupyter. It incorporates similar features to what you have built, particularly the TableReport. Buckaroo has some slightly different aims, but we're working on similar stuff and there might be room to collaborate.

Core aims of Buckaroo:

1. Buckaroo is built around viewing the table first.
2. Views can be quickly toggled through. This means each view can be opinionated and the user can find the view they are looking for quickly.
3. The latest release adds lazy row loading so all rows from a dataframe can be scrolled through and sorted.
4. Buckaroo has some summary stats, but that isn't my wheelhouse so they aren't as comprehensive as skrub
5. Buckaroo is built to be extensible and configurable, plumbing in different analysis and stylings.

In my view building an interactive table widget is a large endeavor, so is building data cleaning and summary stats.
Would you be open to exploring collaboration with this approximate split, buckaroo handles the table and graphical widgets, skrub handles the stats and analysis?

Always happy to talk to other people building cool data tools,
Paddy

[GaelVaroquaux]

Hi Paddy, Thanks a lot for your message. Quick question: does buckaroo work without Jupiter?

…

On Nov 15, 2024, 21:04, at 21:04, Paddy Mullen ***@***.***> wrote: Hello, I have been taking a look at Skrub and it's impressive work - well done. I created [Buckaroo](https://github.com/paddymul/buckaroo) to improve the default dataframe viewing experience in Jupyter. It incorporates similar features to what you have built, particularly the TableReport. Buckaroo has some slightly different aims, but we're working on similar stuff and there might be room to collaborate. <img width="773" alt="Screenshot 2024-11-15 at 2 56 44 PM" src="https://github.com/user-attachments/assets/b8f73e6f-1df5-4119-9544-170211e2eeeb"> Core aims of Buckaroo: 1. Buckaroo is built around viewing the table first. 2. Views can be quickly toggled through. This means each view can be opinionated and the user can find the view they are looking for quickly. 3. The latest release adds lazy row loading so all rows from a dataframe can be scrolled through and sorted. 4. Buckaroo has some summary stats, but that isn't my wheelhouse so they aren't as comprehensive as skrub 5. Buckaroo is built to be [extensible](https://paddymul.github.io/buckaroo-examples/lab/index.html?path=Extending-pandas.ipynb) and [configurable](https://paddymul.github.io/buckaroo-examples/lab/index.html?path=styling-howto.ipynb), plumbing in different analysis and stylings. In my view building an interactive table widget is a large endeavor, so is building data cleaning and summary stats. Would you be open to exploring collaboration with this approximate split, buckaroo handles the table and graphical widgets, skrub handles the stats and analysis? Always happy to talk to other people building cool data tools, Paddy -- Reply to this email directly or view it on GitHub: #1140 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[paddymul]

Buckaroo doesn't currently have a static export mode. I could build one around this JS Only example click on "main" to toggle to different views . There are even methods on the widget that essentially generate that code, to_widgetdcfecell_ex that I use for testing the JS without Jupyter.

By default (non-lazy-mode), Buckaroo bakes in a serialization of the base DataFrame, the summary stats, and different styling configs. Toggling between these views happens without Jupyter.

The more advanced bits of Buckaroo interactivity - search, post_processing functions, the lowcode UI, and auto-cleaning will always require a Jupyter kernel to interact with.

Lazy loading of an entire DataFrame could be made to work with a static export, but the static export would be huge. That size will shrink down when I add an arrow/parquet transport.

[jeromedockes]

Thanks for starting this discussion -- Buckaroo seems to be super useful and a very cool tool! I guess they make different tradeoffs, with buckaroo being more powerful while relying on interaction with a python interpreter for some of its functionality, whereas the tablereport has the constraint of being standalone and is more limited. maybe there could be a way to give a choice to the user, using the static tablereport by default but offering the buckaroo view when we are a notebook and buckaroo is installed?

Re. the buckaroo static export just to make sure I understand correctly: jupyter and jupyter widgets are still needed to create the widget, but once that is done it could be possible to export it to a static web page?

[paddymul]

They do make different tradeoffs. I guess my ask would be, as you think of adding more interactivity for your table, consider buckaroo. The buckaroo widget uses the buckaroo framework (informal term) that I have developed to make building apps like this easy.

So far as static export, I'm currently porting buckaroo to build on top of https://anywidget.dev/ . Anywidget does a much better job of packaging js than my previous setup. I have tried exporting a notebook to a static html file, and the artifact is very close to working.

[paddymul]

What would be a good initial feature that could be enhanced with buckaroo?

Taking a look at https://skrub-data.org/stable/auto_examples/04_fuzzy_joining.html

I think those examples could be enhanced in the interactive context in the following ways.

1. Choosing a base background color for columns based on origin table.
2. Coloring the join column with a color_map based on skrub_Joiner_distance
3. The fact that sort is built into buckaroo. This means when actually figuring out how the tables should join, you are outputting the joined table once in a single cell, not typing multiple incantations of df.sort_values, df.head(), df.tail()
4. As a more advanced feature, the lowcode UI could be used to tweak different join parameters, so you can interactively try different solutions.

I will try to code up some examples of what I have in mind. Note: I'm about to head out on a two week vacation, so it could be a while.

[jeromedockes]

I will try to code up some examples of what I have in mind. Note: I'm about to head out on a two week vacation, so it could be a while.

I think the skrub developers need to discuss a bit how we see the evolution of the tablereport before you invest time in this, to make sure we don't end up wasting your efforts! hopefully we can use that 2-week window and get back to you with more concrete answers :)