[GitHub] tinkerpop pull request #594: TINKERPOP-1577 Building gremlin-python with pyt...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #594: TINKERPOP-1577 Building gremlin-python with python 2/3

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/594
  
VOTE +1.


---
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 #594: TINKERPOP-1577 Building gremlin-python with python 2/3

[davebshow]

Github user davebshow commented on the issue:

https://github.com/apache/tinkerpop/pull/594
  
Tested using mvn clean install with .glv file. Gremlin tests ran 
successfully against Python 2.7 and Python 3.5 interpreter.

VOTE +1


---
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 #594: TINKERPOP-1577 Building gremlin-python with python 2/3

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/594
  
I think the existing documentation covers it, because it already discusses 
virtualenv which is responsible for setting up the different python 
environments to test against. 


---
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 #594: TINKERPOP-1577 Building gremlin-python with python 2/3

[davebshow]

Github user davebshow commented on the issue:

https://github.com/apache/tinkerpop/pull/594
  
Should this include documentation on how to run against the different 
interpreters?


---
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 #594: TINKERPOP-1577 Building gremlin-python with pyt...

[spmallette]

GitHub user spmallette opened a pull request:

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

TINKERPOP-1577 Building gremlin-python with python 2/3

https://issues.apache.org/jira/browse/TINKERPOP-1577

I'd forgotten that I'd long ago made this change to the python build. It 
basically sets up two separate python environments with virtualenv - one for 
python 2.x and one for 3.x - so that we can test both versions against our 
code. 

VOTE +1

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

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1577

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

https://github.com/apache/tinkerpop/pull/594.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 #594


commit ae8306c92bfa5bc5644d0793124e929b47f9b8f9
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2017-03-02T12:01:47Z

TINKERPOP-1577 Added support for building gremlin-python with python 2.x 
and 3.x




---
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: Building gremlin-python

[David Brown]

Nice work with this Stephen! One thing: if I am thinking about this
correctly, pip isn't a requirement for building. I think we are only
using pip inside the virtualenv, and since the virtualenv binary
installs pip and setuptools by default when in creates the
environment, I don't think we need it to be installed on the system.
So basically, if you have Python(2) on on your machine, you only need
to make sure that you install virtualenv before building...make sense?
or am I missing something?

On Tue, Aug 30, 2016 at 5:32 PM, Stephen Mallette  wrote:
> With some help from Dave I've tweaked up the build for python some more -
> the command to build is still:
>
> mvn clean install -pl gremlin-python -DglvPython
>
> but now:
>
> + The prereqs for building are just python 2.7, pip and virtualenv
> + The build uses virtualenv to isolate the python environment to the
> /target directories
> + -DskipTests is now better respected by Gremlin Server - won't bother to
> start it, if tests are skipped
> + Minor adjustments to the deploy phase for python. We can't really deploy
> to pypi on deploy in our release process because pypi has no staging
> environment (like sonatype does) so the release would be immediately public
> prior to vote on the release. So i made a special "-Dpypi" that activates a
> profile that will hook into "mvn deploy" and push the artifacts to pypi
> with twine.
>
> Note that these changes are all in the "virtualenv" branch at the moment. I
> suspect I will merge it to master tomorrow after some more tests.
>
>
>
> On Mon, Aug 29, 2016 at 5:45 PM, Dylan Millikin 
> wrote:
>
>> Yeah this is great. Will be useful for all GLVs.
>>
>> On Mon, Aug 29, 2016 at 6:13 PM, David Brown  wrote:
>>
>> > Wow Stephen thanks for all your hard work! This will really make
>> > driver development a lot easier.
>> >
>> > On Sun, Aug 28, 2016 at 6:48 PM, Stephen Mallette 
>> > wrote:
>> > > Took me half of my Sunday, but I just got Gremlin Server to start up
>> and
>> > > shutdown in the standard maven integration-test phase of
>> gremlin-python.
>> > > That means we can now write native python tests that round-trip to
>> > Gremlin
>> > > Server in addition to the regular unit tests with pytest we already
>> > have! I
>> > > actual  Note that I actually start two gremlin servers one with auth on
>> > and
>> > > one without (ports 8183/8182 respectively) so that we can test
>> > > authentication features. Further note that native tests are bound to
>> the
>> > > integration-test phase of maven and run automatically on -glvPython.
>> > that's
>> > > a bit different from our other projects where integration test phases
>> > only
>> > > run if you -DskipIntegrationTests=false. gremlin-python won't obey that
>> > > setting.
>> > >
>> > >
>> > >
>> > > On Sat, Aug 27, 2016 at 6:05 AM, Stephen Mallette <
>> spmalle...@gmail.com>
>> > > wrote:
>> > >
>> > >> Now that gremlin-python has been merged to master, you might wonder
>> > about
>> > >> what this has done to our build/release process. Well, not very much.
>> If
>> > >> you do your standard
>> > >>
>> > >> mvn clean install
>> > >>
>> > >> on master right now you should see that everything builds and is good
>> to
>> > >> go - even gremlin-python. So, everything is good, right? right? well,
>> > yes
>> > >> and no.
>> > >>
>> > >> The "yes" aspect here is that the entire project still builds with
>> maven
>> > >> which keeps our build toolchain simple. Users can just have java
>> > installed
>> > >> as they always did and still get a clean build of TinkerPop. The "no"
>> > >> aspect is that native python tests (and if you were deploy,
>> > >> packaging/deployment tasks) did not execute.
>> > >>
>> > >> What's good however is that even the native python build tasks are
>> still
>> > >> just part of the maven toolchain. You just need to have python 2.x
>> > >> installed and, if you do, build with:
>> > >>
>> > >> mvn clean install -DglvPython
>> > >>
>> > >> You will now see in your output the results of native pytest
>> execution.
>> > I
>> > >> think this approach almost sets the basic pattern for future GLVs. I'd
>> > >> prefer to not have -glvPython to some degree and simply detect python
>> on
>> > >> the system and then execute natively if it can, but then i think about
>> > what
>> > >> happens as we add more GLVs and then i sorta like the idea of having
>> the
>> > >> specific option to turn things on and off.
>> > >>
>> > >>
>> > >>
>> >
>> >
>> >
>> > --
>> > David M. Brown
>> > R.A. CulturePlex Lab, Western University
>> >
>>



-- 
David M. Brown
R.A. CulturePlex Lab, Western University

Re: Building gremlin-python

[David Brown]

Wow Stephen thanks for all your hard work! This will really make
driver development a lot easier.

On Sun, Aug 28, 2016 at 6:48 PM, Stephen Mallette  wrote:
> Took me half of my Sunday, but I just got Gremlin Server to start up and
> shutdown in the standard maven integration-test phase of gremlin-python.
> That means we can now write native python tests that round-trip to Gremlin
> Server in addition to the regular unit tests with pytest we already have! I
> actual  Note that I actually start two gremlin servers one with auth on and
> one without (ports 8183/8182 respectively) so that we can test
> authentication features. Further note that native tests are bound to the
> integration-test phase of maven and run automatically on -glvPython. that's
> a bit different from our other projects where integration test phases only
> run if you -DskipIntegrationTests=false. gremlin-python won't obey that
> setting.
>
>
>
> On Sat, Aug 27, 2016 at 6:05 AM, Stephen Mallette 
> wrote:
>
>> Now that gremlin-python has been merged to master, you might wonder about
>> what this has done to our build/release process. Well, not very much. If
>> you do your standard
>>
>> mvn clean install
>>
>> on master right now you should see that everything builds and is good to
>> go - even gremlin-python. So, everything is good, right? right? well, yes
>> and no.
>>
>> The "yes" aspect here is that the entire project still builds with maven
>> which keeps our build toolchain simple. Users can just have java installed
>> as they always did and still get a clean build of TinkerPop. The "no"
>> aspect is that native python tests (and if you were deploy,
>> packaging/deployment tasks) did not execute.
>>
>> What's good however is that even the native python build tasks are still
>> just part of the maven toolchain. You just need to have python 2.x
>> installed and, if you do, build with:
>>
>> mvn clean install -DglvPython
>>
>> You will now see in your output the results of native pytest execution. I
>> think this approach almost sets the basic pattern for future GLVs. I'd
>> prefer to not have -glvPython to some degree and simply detect python on
>> the system and then execute natively if it can, but then i think about what
>> happens as we add more GLVs and then i sorta like the idea of having the
>> specific option to turn things on and off.
>>
>>
>>



-- 
David M. Brown
R.A. CulturePlex Lab, Western University

Building gremlin-python

[Stephen Mallette]

Now that gremlin-python has been merged to master, you might wonder about
what this has done to our build/release process. Well, not very much. If
you do your standard

mvn clean install

on master right now you should see that everything builds and is good to go
- even gremlin-python. So, everything is good, right? right? well, yes and
no.

The "yes" aspect here is that the entire project still builds with maven
which keeps our build toolchain simple. Users can just have java installed
as they always did and still get a clean build of TinkerPop. The "no"
aspect is that native python tests (and if you were deploy,
packaging/deployment tasks) did not execute.

What's good however is that even the native python build tasks are still
just part of the maven toolchain. You just need to have python 2.x
installed and, if you do, build with:

mvn clean install -DglvPython

You will now see in your output the results of native pytest execution. I
think this approach almost sets the basic pattern for future GLVs. I'd
prefer to not have -glvPython to some degree and simply detect python on
the system and then execute natively if it can, but then i think about what
happens as we add more GLVs and then i sorta like the idea of having the
specific option to turn things on and off.