I guess i say pip is required because you use pip to install virtualenv.....
On Tue, Aug 30, 2016 at 6:12 PM, David Brown <[email protected]> wrote: > Aha, that is in the virtualenv too... > > On Tue, Aug 30, 2016 at 6:06 PM, David Brown <[email protected]> wrote: > > Ah wait, I guess you use it to install twine. > > > > On Tue, Aug 30, 2016 at 5:58 PM, David Brown <[email protected]> > wrote: > >> 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 > > > > > > > > -- > > David M. Brown > > R.A. CulturePlex Lab, Western University > > > > -- > David M. Brown > R.A. CulturePlex Lab, Western University >
