Feature Request: connection or module-wide config (possibly just for BoxRendererConfig?)

[NickCrews]

I am working in marimo. When displaying DuckdbPyRelations, it assumes a console width of like 70. I want it to have the behavior of jupyter, where the width is unbounded (because I can horizontally scroll).

Either

1. detect marimo environment as jupyter. This is probably death by a thousand papercuts and we don't want to worry about all these cases.
2. allow me to better override the default display config. I can currently do .show(max_width=10000000), but I have to do that on every call. I want to be able to set this once and then all future calls use it

Possible implementations (in order of preference)

1. add a connection-wide method that hooks into and extends the duckdb-native configuration system. eg con.config.set("memory_limit", "10GB") would result in calling SET memory_limit = '10GB', and con.config.get("memory_limit")would result in callingSELECT current_setting('memory_limit') . Then, we add in our extended config names, such as default_show_max_width. IDK if it would be possible to use the duckdb extension API to actually make these be native to duckdb, so that FROM duckdb_settings()` would include it? If not, then we just store the config state in the DuckdbPyConnection c++ class.
2. Make it so that duckdb.__jupyter__ is writable. Currently we init it to True/False at import time, but then if I modify it, it has no effect, because the DuckdbPyRelations::Print() function recomputes this using DuckDBPyConnection::IsJupyter() on every call. Or make it so that there is a DuckDBPyConnection.__is_jupyter__ attribute, which is writable by me, and is used in this function. But still this is half-baked, since I also would like (to a lesser degree) to be able to permanently configure eg max_col_width, max_rows, etc. The full on config API would be better here.

[paultiq]

Perhaps a method to register a _repr_html_? This would work in both Jupyter and Marimo.

* The code below just demonstrates the hook, but something more sophisticated could be implemented with default options/etc, all living in the .py side of the bindings.
** I like _repr_markdown_ as it's cleaner to copy to GitHub issues.

import duckdb 
duckdb.DuckDBPyRelation._repr_html_ = lambda self: "<br/>My Data Is<br/>" + self.df().to_html()
duckdb.sql("select * from range(10)")

I work a lot with Jupyter, but I don't like the IsJupyter() implementation: there's too many assumptions baked in. I'd rather see less 'detection' logic in the DuckDB bindings, and more registration & callbacks... such as the progress bar callbacks.