If the interpreters get moved out of the spark interpretergroup, they won't be 
able to access spark.

> On Apr 6, 2016, at 2:49 AM, Eric Charles <e...@apache.org> wrote:
> 
> C) sounds also logical to me. It follows closer the implementation.
> 
>> On 05/04/16 20:58, Jeff Steinmetz wrote:
>> I actually was thinking about an idea similar to option C before this topic 
>> came up.
>> 208 is Knitr friendly, so r.r and r.knitr as a clear differentiator between 
>> the 702 spark.r interpreter makes sense to me.
>> 
>> B also looks like an decent option as well, but my preference is C.
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 4/5/16, 11:18 AM, "Leemoonsoo" <g...@git.apache.org> wrote:
>>> 
>>> Github user Leemoonsoo commented on the pull request:
>>> 
>>>    
>>> https://github.com/apache/incubator-zeppelin/pull/815#issuecomment-205928501
>>> 
>>> 
>>>    Regarding, name conflict, i can come up with some options.
>>> 
>>>    a. Keep the same name 'spark.r' for both 
>>> [SparkRInterpreter](https://github.com/apache/incubator-zeppelin/blob/master/spark/src/main/java/org/apache/zeppelin/spark/SparkRInterpreter.java)
>>>  and 
>>> [RRepl](https://github.com/apache/incubator-zeppelin/blob/master/r/src/main/java/org/apache/zeppelin/rinterpreter/RRepl.java).
>>>    And let user select it in build time using maven profile, -Pr for RRepl, 
>>> -Psparkr for SparkRInterpreter, or select it in a runtime using 
>>> `zeppelin.interpreters` property in conf/zeppelin-site.xml
>>> 
>>>    b. Change SparkRInterpreter name to 'spark.sparkr', similar to 
>>> PySparkInterpreter uses the name 'spark.pyspark'
>>> 
>>>    c. Change RRepl, and KnitR name from 'spark.r', 'spark.knitr' -> 'r.r', 
>>> r.knitr'.
>>>    And make RRepl and KnitR more like generic R support rather than SparkR 
>>> support. Similar to what 
>>> [ZEPPELIN-502](https://issues.apache.org/jira/browse/ZEPPELIN-502) trying 
>>> to do for python
>>> 
>>> 
>>>    Personally, i'm good with all three options and prefer c) as a long term 
>>> plan, while my guess is many R users will use r without sparkr integration.
>>> 
>>>    What do you think?
>>> 
>>> 
>>> ---
>>> If your project is set up for it, you can reply to this email and have your
>>> reply appear on GitHub as well. If your project does not have this feature
>>> enabled and wishes so, or if the feature is enabled but not working, please
>>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>>> with INFRA.
>>> ---
>> 

Reply via email to