I volunteer to write a doc for the zeppelin documentation site on step by step for adding an "external interpreter" targeted for non developers who wants to add someone's else external interpreter. The challenge I see is from where to get the compiled interpreter from? - my answer is to have a list of external interpreter on our site which points to the github of the external interpreter and the user will download himself. - I think this should help with licensing issues as well as an external site can hold a non apache license interpreter (MySQL, Oracle)
Eran On Thu, Jul 23, 2015 at 2:38 AM moon soo Lee <m...@apache.org> wrote: > Thanks for the opinions and feedback. > > My question was more like simply asking about merging code that does not > have test, but apparently went back to recurrent subject. :-) > > Actually, plug'n'play interpreter is already possible by dropping all the > necessary jars under interpreter/[name] directory and add config to > zeppelin-site.xml. I think nothing stops making externally managed > interpreter. > > I think having list of all internal + external interpreters in homepage or > wiki and let user update it would help, as a first step. > > Best, > moon > > On Wed, Jul 22, 2015 at 9:42 PM Paul Curtis <pcur...@maprtech.com> wrote: > > > +1 > > > > I agree with tog ... the core interpreters should be those that can > > complete all the tests and provide the functionality as well. Spark local > > being the best example. The Apache Drill interpreter I wrote would need a > > single node Drill installation in order to provide the same testing > > capability. I am working to provide this. > > > > However, I would suggest that review may be needed. As each test and > > interpreter adds Zeppelin code, it also adds to the distributable as > well. > > Currently, the distributable is around ~500MB in size. Is the goal to > > provide a completely standalone Zeppelin with all the interpreters and > > environments included? Or is the goal to provide a front end to those > > environments? > > > > Maybe that's the decision: which environments and interpreters are > included > > in a standalone distribution. > > > > paul > > > > On Wed, Jul 22, 2015 at 7:52 AM, IT CTO <goi....@gmail.com> wrote: > > > > > I think that we can have the interpreters add in the build system using > > > compilation parameters (e.g. same as the list in the zeppelin-env.xml > > that > > > way the basic build builds only the core interpreters and the user can > > > easily interperters to the build process. > > > With regard to a release, this can be just as adding the jar and the > > config > > > or just the jar with auto-discovery > > > Eran > > > > > > On Wed, Jul 22, 2015 at 1:40 PM DuyHai Doan <doanduy...@gmail.com> > > wrote: > > > > > > > If we want to make the intepreters system modular to decouple souce > > code, > > > > the process of activating an interpreter should be flexible and easy > to > > > > use. > > > > > > > > Asking end-users to make a custom build is not a viable strategy. > > > Recently > > > > I've seen some people trying to make a custom build of Zeppelin and > > > facing > > > > a lot of issues (incorrect Maven version, no Bower installed, > incorrect > > > > repository policies settings for Maven etc ...) > > > > > > > > Ideally, activating an interpreter should be as simple as dropping a > > jar > > > > into the lib directory > > > > > > > > On Wed, Jul 22, 2015 at 12:28 PM, <felixcheun...@hotmail.com> wrote: > > > > > > > > > +1 what tog says > > > > > > > > > > > > > > > > > > > > > > > > > From: tog > > > > > > > > > > Sent: Wednesday, July 22, 12:22 AM > > > > > > > > > > Subject: Interpreter with no test. > > > > > > > > > > To: dev@zeppelin.incubator.apache.org > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > This seems to be a recurrent topic ;-) > > > > > > > > > > > > > > > It has to be decided what are the core interpreters the Zeppelin > want > > > to > > > > > > > > > > support - then I would believe you can have a wiki/webpage > dedicated > > to > > > > > > > > > > listing all interpreters that are known to be working with > Zeppelin. > > > You > > > > > > > > > > may even consider having recommended plugins and/or ranking in > case 2 > > > > > > > > > > plugins are doing the same job. Grails (but it is probably not the > > only > > > > > > > > > > one) is implementing this (see https://grails.org/plugins/) > > > > > > > > > > > > > > > In order to keep Zeppelin low in term of footprint - the core > > commiters > > > > can > > > > > > > > > > even decide to support some of those plugins (shell for example) > > > > > > > > > > At one end of the spectrum you could imagine Zeppelin without any > > > > > > > > > > interpreters and at the other end Zeppelin with all known plugins - > > the > > > > > > > > > > truth is probably in the middle. > > > > > > > > > > > > > > > > > > > > On Wednesday, July 22, 2015, Anthony Corbacho < > > > > anthonycorba...@apache.org > > > > > > > > > > <javascript:_e(%7B%7D,'cvml','anthonycorba...@apache.org');>> > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > IT CTO is right, right now, zeppelin merge every interpreter in > the > > > > code > > > > > > > > > > > base and its mean that we (committer) have to take care of build > > > > falling > > > > > or > > > > > > > > > > > questions for those interpreters. and personally i have no > > experience > > > > in > > > > > > > > > > > presto, cassandra etcetc. > > > > > > > > > > > > > > > > > > > > > > I think, It can be interesting to detach interpreters from > zeppelin > > > > code > > > > > > > > > > > base and create a sortof plug'n'play module where the users can > > plug > > > > the > > > > > > > > > > > interpreter he wants to use. > > > > > > > > > > > > > > > > > > > > > > With this approach, we can keep zeppelin code base smaller (we > > > provide > > > > > the > > > > > > > > > > > core + maybe some interpreters (spark, md, shell) as default). > and > > > the > > > > > > > > > > > community can build and manage other interpreters (i assume if > they > > > > build > > > > > > > > > > > it they have experiences and probably can answer questions). > > > > > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 22, 2015 at 2:34 PM, IT CTO <goi....@gmail.com> > wrote: > > > > > > > > > > > > > > > > > > > > > > > I think the question is what\who is going to fix issues in > these > > > > > > > > > > > > Interpreters if something fails? > > > > > > > > > > > > I am guessing that if one uses these interpreters and approach > > the > > > > > > > > > > > > community with questions then we might not have the right > support > > > for > > > > > > > > > > > him. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 22, 2015 at 8:04 AM moon soo Lee <m...@apache.org> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi folks, > > > > > > > > > > > > > > > > > > > > > > > > > > There're some open pullrequests with complete interpreter > > > > > > > > > > > implementation > > > > > > > > > > > > > but no test (eg. > > > > > https://github.com/apache/incubator-zeppelin/pull/110 > > > > > > > > > > > , > > > > > > > > > > > > > https://github.com/apache/incubator-zeppelin/pull/68). > > > > > > > > > > > > > > > > > > > > > > > > > > Personally, I'm feeling not safe having code without test, > but > > at > > > > the > > > > > > > > > > > > same > > > > > > > > > > > > > time, keeping these great contributions unmerged sounds not > > cool. > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to hear opinions about merging them with some mark > > such > > > as > > > > > > > > > > > > 'beta' > > > > > > > > > > > > > or 'untested', and create issue for adding test. > > > > > > > > > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > moon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > PGP KeyID: 2048R/EA31CFC9 subkeys.pgp.net > > > > > > > > > > > > > > > > > > > > -- > > *Paul Curtis - *Senior Product Specialist - Field Enablement Team > > *O: *+1 203-660-0015 - *M:* +1 203-539-9705 > > > > > > Now Available - Free Hadoop On-Demand Training > > < > > > http://www.mapr.com/training?utm_source=Email&utm_medium=Signature&utm_campaign=Free%20available > > > > > >
