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 >
