☰Read-only archive⌕
Looking for help with Bokeh?

This is a read-only archive. Ask questions and join the conversation on GitHub.

Visit Community Support on GitHub →
Archived discussions · Captured October 28, 2026

Creating pip/conda package for Bokeh custom model

Community Support
mateusz
mateusz

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.

⌁   Link to post
Luke_Canavan
Luke_Canavan

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.

⌁   Link to post
Bryan
Bryan

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.

⌁   Link to post

End of archived discussion · Replies are disabled