BokehJS and node.js integration #1589
Comments
|
I have been experimenting trying to get the following to execute in node: I had to install node packages: navigator, jsdom, jquery, as well as apply the following patch to Ultimately I am sure it would be better to split off the non-widget, non-UI (tools) part of BokehJS to make it easier to use with node, but if there is something to be done in the short term, we should. |
|
@tswicegood probably has some comments |
|
I pinged @tswicegood at the top. :) |
|
@bryevdv are you getting any errors when trying to run this? I don't currently have a development version of bokeh setup so I haven't tried your code but it looks roughly right (ignoring any potential issues with require.js/r.js). Andrew and I just worked through setting up Backbone with Mocha in Node.js (using Browserify, though). One thing we did differently was use the |
|
Yes it blows up at the |
|
Yeah -- at that point something is not shimmed correctly. Can you post in the stack trace? |
|
I was able to correctly load bokehjs in node. The problem was that some of bokehjs' dependencies try to be smart and behave like node modules when they think is necessary. The effect was that This is far from getting plots to render. Currently, although I load |
|
So that was for |
|
For now I wasn't able to get anywhere near rendering a plot in node.js. Currently the issue is that node.js abruptly terminates when I try to use any HTML fragment that contains I tried different versions of node.js, including development 0.11.x branch. |
|
To reproduce my results, you can use the following code: |
|
Looking at |
|
If you run above code under PR #1797, you will get: despite |
|
ping @tswicegood actually lets keep comments in the issue, as the current PR may not cover the entire discussion. |
|
This just popped up in my feed again because of the activity. FWIW, I would seriously consider browserify when you head down the route of moving to Node. I know @mattpap has some custom build tooling in place that relies on Require.js, but I believe the benefits of Browserify are pretty significant:
And most importantly: Brings Bokeh and the new Anaconda Launcher platform together on the same build chain. You can see a full project written out using CommonJS + Browserify in this part of the tree (note that it's node-webkit, so I played around with switching to Browserify back last fall without a full development environment setup. I was able to get it to compile within an afternoon, though, as I said, I didn't have a dev environment setup so I'm not sure how much additional work would be necessary. |
|
@tswicegood is this something you could devote a day or two to helping with sometime in the next month or two? I would love to come to LA and bang this out as well as some other server improvements, in a super-focused sprint. |
|
To be clear, I think the current work should be merged right after 0.8.1 :) |
|
My custom build isn't that big deal, I will figure this out. However, to note this, switching to browserify isn't going to help this issue. The problem we are dealing with here is that node.js libraries are just not mature enough to handle complex piece of code as bokehjs is. |
|
@mattpap right I realize that, but it seems like a nice transition nonetheless. Regarding node.js and bokeh specifically, do you characterize things as completely hopeless at this point, or is there some useful subset that will work, or perhaps upstream contributions we could make? |
I don't negate that. I just want make sure that in this issue we stay focused solving the actual problem.
It's not hopeless. Maybe there is some workaround of jsdom's issues, or perhaps jsdom could be improved. I don't know node.js internals, so I can't say anything more right now. However, I think that it would be better to make bokehjs DOM independent, as much as possible. Then could use node-canvas directly. |
|
I agree, let's hash out a plan of for that after this PR is merged (hopefully later today) |
|
@bryevdv sure. The next few weeks are a bit busy, but past that I should have some time. I'm going to be in Austin in late March it looks like, but if you wanted to come out before then we could bang it out. |
|
Since #1797 was merged, do you want to continue further discussion here? or can this one be closed? |
|
@damianavila, #1797 doesn't resolve this issue (just makes the first step towards fixing it). |
|
yes... I know... this is why I asked if you want to keep the discussion centralized here... ok, I will label #1797 properly, thanks! |
|
@mattpap I'd like your opinion on the following question: How feasible would it be to:
and
This would be useful on two fronts:
All of these things can be ignored / don't need to function:
Did the problems en encountered intersect with the smaller subset of functionality we could need ? Could they be worked around? |
|
Creating a log of actions should be easy indeed, but I'm worried it may be too big for any practical purpose. Unit testing seems an interesting idea, but it depends whether this approach will be actually faster and more robust than image diff. |
I'm not so sure about that. You have to make sure that pycairo's canvas semantics match exactly HTML5 canvas. Otherwise, you would have to implement a layer on top of pycairo. Note that there is already such effort for node.js, i.e. node-canvas. |
For sure, we should investigate whether JS things have moved on since the last time we looked. I have used cairo pretty extensively in the past, which is why I am thinking of it. The semantics are definitely similar enough that a translation from one to the other would be straightforward, if not trivial. |
|
@mattpap also I am suggesting adding the kinds of unit tests in addition to the image diff tests. Then we could have some quick jobs across platforms that do nothing but unit tests, and another job that does nothing but image diff tests, and perhaps by splitting things up we can achieve an overall time reduction. |
|
Hi all. Is headless output as vector graphic formats something that is likely to be included in a release in the foreseeable future, e.g. in 0.11? I am about to start working on a new project that this would be fairly vital to, and I'd love to be able to commit to using Bokeh for it. |
|
It's definitely not going to be in We are pushing through two big architectural efforts (the server re-write in tornado, and splitting up BokehJS) as well as some larger features that are immediately relevant to some current engagements (Annotations, GIS and tile rendering). Static output is an important priority, unfortunately there are lots of important priorities, and it's also a very technically challenging one as well. That said, splitting BokehJS and into more manageable pieces will help towards being able to run parts of it in node.sat , and it's also possible node.js and node-canvas have developed further in the mean time as well. @mattpap do you have any notion of recent developments that might make this easier/better now? |
Currently not, but I'm giving this another try. |
|
@bryevdv, I'm favor of closing this issue as resolved, at least per its title. bokehjs and node.js integration is fairly reliable since PR #5129. As commented in that PR, bokehjs shouldn't assume anything about the environment, so it shouldn't depend neither on jsdom nor node-canvas. Further discussion should be continued in issue #538. An additional bundle is needed on top of bokehjs. However, I doubt bokehjs will be ever able to render static plots reliably in node.js. I think we should go ahead with headless chromium or similar. In such case, current bokehjs-node.js integration is sufficient. |
|
sounds good to me. |
This is a necessary prerequisite to adopting
node-canvasfor headless static output as described in #538.@mattpap and @tswicegood your input is very appreciated when you have time.
The text was updated successfully, but these errors were encountered: