Creating pip/conda package for Bokeh custom model

I’m looking at the LatexLabel custom model here: bokeh/latex_extension.py at aa8f3028e1b02a438f740116b127ded280f18038 · bokeh/bokeh · GitHub

While it’s presumably possible to vendor the example into a project, are there any technical barriers to building the model into a pip/conda package and importing the custom model from there?

In general, has anybody tried to make a python package from a custom model?

The biggest issue is that compilation of bokeh extensions currently happens at the use site, which is slow to work with and requires the user have the necessary development stack installed (nodejs, etc.). There is also no effective way to precompile extensions and e.g. put them on a CDN. I’m currently working on improving the extensions’ development workflow. This should be done the next week or two.

Thanks for the explanation @mateusz.

My proposed use case is making the LaTexLabel custom model example into a pip/conda package, so can users can use Tex without having to vendor in the example or manually install the extension dependencies. Since it’ll mostly be used for SVG generating figures for papers (and not really deployed), I think the slow compilation step is fine.

I don’t think there is any technical barrier to doing this.

As to why I have not personally pushed anything like this, it is mostly a matter of the the perfect being the enemy of the good. I had in mind something similar to Atom, VSCode, Discourse, i.e a system where plugins are simply GitHub repositories. I consider this more ideal for a few reasons:

  • Barrier to entry is lower— publishing Python packages is a not trivial. And what kind? Pip packages? Conda packages? Would extension authors have to provide both?

  • Extension versions could just be tags in GH. No need to publish extensions on PyPI or anaconda.org all the time

  • Could potentially have amazing user experience for plugins like Atom and VSCode have

So what are the cons?

  • Unclear how to handle either Python dependencies or dependencies between plugins. I think the vast majority of extensions are likely to be self-contained, so much so that this concern is outweighed.

  • Less clear what “installing” an extension means.

The last one is the big one and probably what sinks the idea for a library (it’s alot more clear what installing means for an app like VSCode, or Atom, or Discourse). I can imagine some solutions, but they are not great. But at this moment in time I’m inclined to leave this project to others, who don’t have my hang-ups about using regular Python packages.

TLDR; At this point I think anyone with a reasonable idea for a plan forward on sharing extensions should just start moving on it.