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 <[email protected]> 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 <[email protected]> > wrote: > >> Yeah this is great. Will be useful for all GLVs. >> >> On Mon, Aug 29, 2016 at 6:13 PM, David Brown <[email protected]> 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 <[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 >> > >> -- David M. Brown R.A. CulturePlex Lab, Western University
