Add Jupyter release workflow and align workflow filenames

[georgestagg]

Release workflow for the ggsql Jupyter kernel binary, to be released under the ggsql-jupyter package on PyPI.

[cpsievert]

Is there a good reason why these should be separate?

[georgestagg]

The --install line creates the required kernel.json spec file for Jupyter and installs it in the right location by invoking jupyter kernelspec install.

I saw the pattern used by other kernels distributed on PyPI, does pip have a concept of a post-install script that could do the same thing?

[cpsievert]

I had Claude investigate, here's what it found. I think the caveat is important enough that we just stick with the current approach?

"pip doesn't have a post-install hook for wheels — modern pip just extracts the wheel directly with no custom code execution (by design, PEP 427). And since this is a maturin bindings = "bin" project with no Python code at all, there's nothing to hook into anyway.

However, there is a clean alternative: maturin supports a .data directory mechanism that can auto-place a kernel.json into the Jupyter kernelspec directory at install time, with no second step required. You'd create:

ggsql-jupyter/
  ggsql_jupyter.data/
    data/
      share/
        jupyter/
          kernels/
            ggsql/
              kernel.json

The data/ subdirectory maps to sys.prefix on install, and Jupyter searches {sys.prefix}/share/jupyter/kernels/ by default. So pip install ggsql-jupyter would automatically register the kernel. The kernel.json argv would just reference ggsql-jupyter by name (since pip puts the binary on PATH in the venv).

Main caveat: this works well for virtualenv/conda installs (the common case), but for pip install --user, sys.prefix points to the system prefix rather than ~/.local, so the kernelspec placement may not be ideal. The --install flag would still be useful as a fallback for non-pip installs (cargo install, binary downloads) and for explicit --user/--sys-prefix targeting."

[georgestagg]

Thanks, that's useful.

Hmmm, it sounds like it would work most of the time but then be annoying when it doesn't. Yes, let's stick with this method for now, the --install argument is useful for replacing the kernel in local development too.