fiber-space / jupyter-kernel-jsr223

A JSR223 compliant Jupyter kernel implementation in Java
Apache License 2.0
60 stars 12 forks source link

Usage as a library #6

Open deas opened 7 years ago

deas commented 7 years ago

I have just started playing around with the kernel. Meanwhile, I consider using it as a library. In fact, that was one of the reasons I mavenized it.

Do you somehow rely on the ant scripts and do you want to keep them around?

With regards to libary usage: I think logging should be tweaked to use something more sophisticated like slf4j instead of raw System.out / System.err. Other than that, I have already tweaked things so that commons-cli becomes optional (for the standalone/main use case).

Would you be interested in changes with regards to usage as a library?

BTW: I found Nashorn to be working pretty much out of the box.

cheers Andreas

eiswind commented 7 years ago

I think I could use it as a library for my java9/jshell fork

fiber-space commented 7 years ago

I would like to not decide how the jupyter-kernel package is used.

I followed a batteries-included approach with respect to JSR223 interpreters, which means that users ideally don't need n additional packages for n language interpreters. I also didn't want users to need Maven and a JDK. Besides this I already introduced changes to facilitate the use of the jupyter-kernel package as a library in particular to support Thorstens jshell use case ( see the final section of the README.md ) and I'm willing to accept more but I want to understand the impact.

About logging. Not exactly sure what you refer to? There are two StringWriter objects in InteractiveConsole.java which are assigned to the engine context. Is it that what you mean? The content of those StringWriters is sent to the Jupyter notebook, not to the server log. It is what the user sees in the notebook when the interpreter of the scripting language sends text to stdout/stderr. One cannot simply augment this with log information, as this would change the meaning of the text.

deas commented 7 years ago

I'd also like to keep things as easy as possible for all parties involved. Basic users should not be forced to deal with ant or maven.

However, I think maven artifacts (preferably on maven central) are helping with the as-a-library use case.

With regards to my use case: I'd like to run the kernel within an application server. Hence, lifecycle is not bound to process lifecycle and logging is also a little different.