Hello,
I created gremlin-python/ package and killed gremlin-variant/ package. Thus,
the links I provided in the email earlier this morning are busted. You can move
around from here to re-find the references.
https://github.com/apache/tinkerpop/tree/TINKERPOP-1278/gremlin-python/src/main
<https://github.com/apache/tinkerpop/tree/TINKERPOP-1278/gremlin-python/src/main>
Thanks,
Marko.
http://markorodriguez.com
> On Jun 22, 2016, at 7:36 AM, Marko Rodriguez <okramma...@gmail.com> wrote:
>
> Hello,
>
> I have been working on TINKERPOP-1278 for a couple of weeks now and here is
> where my thoughts are going.
>
> First, a review of the concepts.
>
> 1. Apache TinkerPop is a JVM-based graph computing framework.
> 2. Gremlin can be embedded/represented in any programming language that
> supports function composition and function nesting.
> - Every programming language supports these two constructs.
> 3. There are two ways in which XXX language can work with Apache
> TinkerPop.
> a.) XXXScriptEngine can directly use TinkerPop classes.
> b.) XXX “mocks” of TinkerPop’s Traversal and RemoteConnection
> in the respective language.
> 4. The language that is representing/hosting Gremlin is called the
> “source language.”
> 5. The language that the Gremlin traversal will ultimately be executed
> on in the JVM is called the “target language.”
> 6. It is the responsibility of a Translator to translate the source
> language into the target language.
>
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java
>
> <https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/Translator.java>
>
> - getAlias() is function naming.
> - addStep(), addSpawnStep(), addSource() is function
> composition.
> - getAnonymousTraversalTranslator() is function nesting.
> - getSourceLanguage() and getTargetLanguage() is
> translator metadata.
> 7. It is possible/reasonable for both source and target languages to be
> on the JVM.
> - For example, Gremlin-Java translating to Gremlin-Groovy so it
> can avoid the complications of serialization and support remote lambda
> execution.
>
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66
>
> <https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/GroovyTranslator.java#L58-L66>
>
> From this foundation, we should work towards the following:
>
> 1. bin/gremlin.sh —language gremlin-python
> - this will load up a GremlinConsole where a
> GremlinJythonScriptEngine is used to read and return results.
> - same gremlin> and ==> look-and-feel, but now its Python, not
> Groovy that is the scripting language.
> - In this way, Python people can work with TinkerPop and NEVER
> leave Python.
> 2. Moving forward, we then have gremlin-jruby and respective
> GremlinJRubyScriptEngine.
> - In this way, Ruby people can work with TinkerPop and NEVER
> leave Ruby.
> 3. Unlike Groovy, Python and Ruby have representations outside of the
> JVM and thus, need VM agnostic code (i.e. they can’t just “new
> GraphTraversal”).
> - PythonGraphTraversal (which is NOT just GraphTraversal used
> by Gremlin-Jython on the JVM).
>
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py
>
> <https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/gremlin_python.py>
> - It is simple to auto generate XXX language
> “mocks” using reflection.
>
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy
>
> <https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/groovy/org/apache/tinkerpop/gremlin/python/GremlinPythonGenerator.groovy>
> - Translators allow for the translation of XXX language
> traversals to YYY language traversals on the JVM for execution by TinkerPop.
>
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/groovy_translator.py
>
> <https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_python/groovy_translator.py>
> When GremlinJythonScriptEngine exists, we should have a
> JythonTranslator as it will natively support lambdas.
> - gremlin_driver, gremlin_rest_driver, etc. which are the
> Python specific replications of the same classes used in JVM TinkerPop.
>
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_driver/gremlin_driver.py
>
> <https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_driver/gremlin_driver.py>
>
> https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_rest_driver/gremlin_rest_driver.py
>
> <https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-variant/src/main/jython/gremlin_rest_driver/gremlin_rest_driver.py>
> 4. All Gremlin language variants distributed by Apache TinkerPop should
> have their own package.
> - gremlin-groovy
> - gremlin-jython (with gremlin-python representation in it)
> - gremlin-jruby (with gremlin-ruby representation in it)
> - gremlin-rhino (with gremlin-js representation in it)
> - gremlin-renjin (with gremlin-r representation in it)
> [http://www.renjin.org/ <http://www.renjin.org/> cool!]
> - etc.
>
> Thoughts?,
> Marko.
>
> http://markorodriguez.com <http://markorodriguez.com/>
>
>
>
>> On Jun 16, 2016, at 10:37 AM, Marko Rodriguez <okramma...@gmail.com
>> <mailto:okramma...@gmail.com>> wrote:
>>
>> Yea — submodules is a good idea.
>>
>> Also, I think we should create gremlin-jython, gremlin-ruby, etc.
>> ScriptEngines that have all the imports loaded and ready to go much like we
>> have with gremlin-groovy.
>>
>> Marko.
>>
>> http://markorodriguez.com <http://markorodriguez.com/>
>>
>>
>>
>>> On Jun 16, 2016, at 10:19 AM, Stephen Mallette <spmalle...@gmail.com> wrote:
>>>
>>> I would think that we want individual plugins for each variant.
>>>
>>> This does lead me back to an earlier discussion about gremlin-variant
>>> packaging. We didn't want to do
>>>
>>> gremlin-variant
>>> +-- gremlin-variant-python
>>> +-- gremlin-variant-js,
>>> +-- ....
>>> +-- gremlin-variant-XXXXX
>>>
>>> so with gremlin-variant users are going to just get everything when they
>>> depend on it. To my knowledge, we are only kinda viewing this from a python
>>> perspective atm and haven't really researched all the languages we support,
>>> but I sense that ultimately as we add more GLVs we're going to end up with
>>> a really messy pom.xml for gremlin-variant with the potential for conflict
>>> as we try to make maven deal with packaging issues for all those disparate
>>> languages. Again, hard to say how much trouble this will eventually be, but
>>> might be worth noodling on again in case anyone has any new thoughts on the
>>> matter.
>>>
>>>
>>>
>>> On Thu, Jun 16, 2016 at 12:10 PM, Daniel Kuppitz <m...@gremlin.guru> wrote:
>>>
>>>> The last few days I've been working on a Gremlin Python code executor for
>>>> the TinkerPop docs. What I noticed was that we can't simply execute Gremlin
>>>> Python code in our Gremlin Groovy console, simply because the console has
>>>> no dependency to the gremlin-variants projects.
>>>>
>>>> That was unfortunate for the docs pre-processor, but what about the normal
>>>> user? Do we need to have those language variants always available or would
>>>> it be sufficient to have a Gremlin-Xyz plugin (where Xyz could be Python,
>>>> Ruby, etc.)?
>>>>
>>>> I've added the "missing" dependency for now to get the docs pre-processor
>>>> extension done, but I think we should remove that dependency again and
>>>> create a plugin instead, before the branch gets merged into master.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>
>
