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 <[email protected]> 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 <[email protected]> > 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
