Currently, ggsql-jupyter --install copies the binary into {LOCAL}/Jupyter/kernels/ggsql/ggsql-jupyter along with kernel.json. Today, this breaks ggsql-jupyter and it cannot start.
Instead, the kernel.json should be written to point to the current installation location of ggsql-jupyter, because we refer to dynamic libraries that we ship with the Jupyter kernel relatively.
The alternative is to no longer ship ODBC libraries with ggsql-jupyter and ask users to install them manually with e.g. brew install unixodbc. But this would affect users who don't require ODBC.
Claude claims statically linking ODBC is no good, but we might also be able to investigate it if as another option we need to.
But I think the easiest quick win is changing how --install works.
EDIT: The extension should also follow links when resolving full path of the installed ggsql-jypyter binary.
Currently,
ggsql-jupyter --installcopies the binary into{LOCAL}/Jupyter/kernels/ggsql/ggsql-jupyteralong withkernel.json. Today, this breaksggsql-jupyterand it cannot start.Instead, the
kernel.jsonshould be written to point to the current installation location ofggsql-jupyter, because we refer to dynamic libraries that we ship with the Jupyter kernel relatively.The alternative is to no longer ship ODBC libraries with
ggsql-jupyterand ask users to install them manually with e.g.brew install unixodbc. But this would affect users who don't require ODBC.Claude claims statically linking ODBC is no good, but we might also be able to investigate it if as another option we need to.
But I think the easiest quick win is changing how
--installworks.EDIT: The extension should also follow links when resolving full path of the installed
ggsql-jypyterbinary.