[GitHub] tinkerpop pull request #345: add license boilerplate to __version__

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/345


---
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.
---

[GitHub] tinkerpop pull request #345: add license boilerplate to __version__

[leifurhauks]

GitHub user leifurhauks opened a pull request:

https://github.com/apache/tinkerpop/pull/345

add license boilerplate to __version__

also import __version__ in setup.py instead of eval-ing it

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/leifurhauks/incubator-tinkerpop 
python_version_license_boilerplate

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/345.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #345


commit 19cf29efa103ed360608cae3baf20298bf9a41bf
Author: Leifur Halldor Asgeirsson 
Date:   2016-06-22T15:52:22Z

add license boilerplate to __version__

also import __version__ in setup.py instead of eval-ing it




---
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.
---

[GitHub] tinkerpop pull request #344: gremlin_python: generate/build/deps before test...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/344


---
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.
---

Re: [DISCUSS] Gremlin Language variants in the Gremlin console

[Marko Rodriguez]

Hi,

Kuppitz just brought up something in chat and I remembered something we did for 
Rexster back in the TinkerPop2 days.

~/software/tinkerpop bin/gremlin.sh

 \,,,/
 (o o)
-oOOo-(3)-oOOo-
plugin activated: tinkerpop.server
plugin activated: tinkerpop.utilities
plugin activated: tinkerpop.tinkergraph
plugin activated: tinkerpop.gremlin-groovy
plugin activated: tinkerpop.gremlin-jython
gremlin> :script-engine
==>gremlin-groovy
gremlin> a = 2
==>2
gremlin> a.getClass()
==>class java.lang.Integer
gremlin> :script-engine gremlin-jython
==>now using gremlin-jython
gremlin> a
==>2
gremlin> type(a)

gremlin>

In short, one Bindings that is moved between ScriptEngine backings. The 
GremlinConsole allows us to jump between languages and keep the same bindings. 
g, graph, etc. In this way, the GremlinConsole is not tied to Groovy, but 
instead, while using the power of Groovysh, can I/O to any ScriptEngine.

Marko.

http://markorodriguez.com



> On Jun 22, 2016, at 7:36 AM, Marko Rodriguez  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
>  
> 
>  
>   - 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
>  
> 
> 
> 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
>  
> 
>   - 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
>  
> 

[GitHub] tinkerpop issue #344: gremlin_python: generate/build/deps before tests

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/344
  
Can you add the license boilerplate? 

BTW: Just pulled your patch and building locally now.


---
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.
---

[GitHub] tinkerpop issue #344: gremlin_python: generate/build/deps before tests

[leifurhauks]

Github user leifurhauks commented on the issue:

https://github.com/apache/tinkerpop/pull/344
  
Also, the generated `__version__.py` file fails the rat check. I think it 
needs to be either
a) generated with the license boilerplate
b) excluded from the rat check, or
c) included in the clean configuration.

Please advise.


---
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.
---

[GitHub] tinkerpop issue #344: gremlin_python: generate/build/deps before tests

[leifurhauks]

Github user leifurhauks commented on the issue:

https://github.com/apache/tinkerpop/pull/344
  
I think this should fix the CI test failures.

On the subject of the python dependencies (aenum and requests), should they 
be bundled in the jar? aenum has a 3-clause BSD 
[license](https://bitbucket.org/stoneleaf/aenum/src/c9dc3b8fc3e3755a919ba4357ab9ed9b22131af1/aenum/LICENSE?at=default=file-view-default),
 and requests uses the ASL.


---
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.
---

[GitHub] tinkerpop pull request #344: gremlin_python: generate/build/deps before test...

[leifurhauks]

GitHub user leifurhauks opened a pull request:

https://github.com/apache/tinkerpop/pull/344

gremlin_python: generate/build/deps before tests

Code generation is triggered by Maven before tests are run; dependencies
(currently aenum, requests) are installed, and the generated package is 
built
into ${project.build.testOutputDirectory}/Lib, which is added to the
classpath for the tests via the python.home property. Jython tests
import the gremlin_python package instead of importing its modules
directly.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/leifurhauks/incubator-tinkerpop 
python_test_fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/344.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #344


commit 252e358d7e0acf519e384da590050c6c55369a29
Author: Leifur Halldor Asgeirsson 
Date:   2016-06-22T13:34:41Z

gremlin_python: generate/build/deps before tests

Code generation is triggered by Maven before tests are run; dependencies
(currently aenum, requests) are installed, and the generated package is 
built
into ${project.build.testOutputDirectory}/Lib, which is added to the
classpath for the tests via the python.home property. Jython tests
import the gremlin_python package instead of importing its modules
directly.




---
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.
---

Re: [DISCUSS] Gremlin Language variants in the Gremlin console

[Marko Rodriguez]

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
 

 
- 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
 


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
 

- 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
 

- 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
 

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