bokeh.js build questions

Community Support
1

I was thinking about how to make things easier for folks to try out bokeh.js, and a few questions came to mind:

  1. would it be possible to just ship hem with bokeh.js? would just be nice to reduce the start-up friction

  2. is it possible to build bokeh.js right now just as a “library”? I’d like to include all the bokeh.js machinery but not make an application.js. Is there just a different slug target that needs to be added?

  3. when should we tag a first release, and and at what version?

  4. would it make sense to make a built, minified release of bokeh.js available through npm?

2

I was thinking about how to make things easier for folks to try out
bokeh.js, and a few questions came to mind:
1) would it be possible to just ship hem with bokeh.js? would just be nice
to reduce the start-up friction

Yes. We have a subtree/ directory at the top level for embedding things
like this. BokehJS is the only project in there right now, but we could
also pull in our fork of Hem.

We do need to do some thinking about how we're going to package releases.
Bokeh itself will most likely be consumed by Python folks, the vast
majority of whom will not want to do a lot of JS/npm/coffeescript
wrangling. So we want a single download that they can use *and* can
integrate nicely into their tools. However, there will be other Python web
programmers that will potentially want to be able to package Bokeh with
their own versions of the dependencies.

2) is it possible to build bokeh.js right now just as a "library"? I'd
like to include all the bokeh.js machinery but not make an application.js.
Is there just a different slug target that needs to be added?

Well, I think if we want that, we should just use cake, or drive cake from
a Makefile or a Python script, to create a bokehjs/ dir that includes the
minified .js of all our dependencies, as well as all the bokehJS source
itself. (I'm personally not a big fan of the application.js stuff.)

3) when should we tag a first release, and and at what version?

Within the next month, after we bake out the Python glyph API, and get
stencil & DSL stuff incorporated. Version 0.1 definitely. :slight_smile:

4) would it make sense to make a built, minified release of bokeh.js
available through npm?

Sure, that's a possibility...

-Peter

···

On Mon, Mar 25, 2013 at 11:17 PM, Bryan Van de Ven <[email protected] > wrote:

3

We do need to do some thinking about how we’re going to package releases. Bokeh itself will most likely be consumed by Python folks, the vast majority of whom will not want to do a lot of JS/npm/coffeescript wrangling. So we want a single download that they can use and can integrate nicely into their tools. However, there will be other Python web programmers that will potentially want to be able to package Bokeh with their own versions of the dependencies.

  1. is it possible to build bokeh.js right now just as a “library”? I’d like to include all the bokeh.js machinery but not make an application.js. Is there just a different slug target that needs to be added?

I think that as a js library, shipping application.js is probably the way to go. In Bokeh our approach is different, we include bokehjs as a subtree for Bokeh, and then we have a slug.json which is manually setup for both. This is because when we develop Bokeh, it is likely that we also need to modify bokehjs. However I doubt other people have those requirements. if we just give them application.js, they should be able to use it.

Well, I think if we want that, we should just use cake, or drive cake from a Makefile or a Python script, to create a bokehjs/ dir that includes the minified .js of all our dependencies, as well as all the bokehJS source itself. (I’m personally not a big fan of the application.js stuff.)

Hem is the only thing that will build our stuff out of the box right now - we would have to modify any other build approach to inject all that require stuff, as well as compile our eco templates. What do you not like about application.js?