Just created an issue to help track these changes: https://issues.apache.org/jira/browse/TINKERPOP-1268
On Mon, Apr 18, 2016 at 11:38 AM, Stephen Mallette <spmalle...@gmail.com> wrote: > I don't think we'd change that for gremlin.sh. The :install command is > sufficient imo. If no one has better ideas for -i on gremlin.sh I'm going > to stick with that. > > On Mon, Apr 18, 2016 at 11:05 AM, Jason Plurad <plur...@gmail.com> wrote: > >> > do you feel really strongly about using something different? >> >> No, just pointing out the inconsistency, unless you think you'll add the >> ability to install Gremlin plugins via the command line for the console >> also. >> >> On Mon, Apr 18, 2016 at 11:01 AM, Stephen Mallette <spmalle...@gmail.com> >> wrote: >> >> > > gremlin-server.sh uses -i to install plugins, so I'd pick a different >> > flag here. >> > >> > dah...that stinks. groovy uses -e and python is -i. since we'd already >> used >> > -e i figured that -i would at least match python. hard to do better >> than -i >> > for gremlin.sh as it's quite memorable for being "interactive mode". >> it's >> > so good, i'd almost ignore the fact that gremlin-server.sh provides >> > different meaning to it. anyone have other ideas for what it could be? >> > jason do you feel really strongly about using something different? >> > >> > > 3.1.3? This isn't considered a breaking change? >> > >> > no - i think it can be done to be backward compatible. if i find it >> can't >> > i'll make sure it happens in 3.2.1. >> > >> > On Mon, Apr 18, 2016 at 10:53 AM, Jason Plurad <plur...@gmail.com> >> wrote: >> > >> > > > 3. Add support for bin/gremlin.sh -i init.groovy >> > > >> > > gremlin-server.sh uses -i to install plugins, so I'd pick a different >> > flag >> > > here. >> > > >> > > > I plan to experiment on these changes in the coming days for 3.1.3 >> > > >> > > 3.1.3? This isn't considered a breaking change? >> > > >> > > -- Jason >> > > >> > > >> > > On Sun, Apr 17, 2016 at 9:35 AM, Stephen Mallette < >> spmalle...@gmail.com> >> > > wrote: >> > > >> > > > We currently have a couple ways to pass files to Gremlin Console for >> > > > execution. We have: >> > > > >> > > > bin/gremlin.sh init.groovy >> > > > >> > > > and >> > > > >> > > > bin/gremlin.sh -e exec.groovy >> > > > >> > > > where the first one executes an initialization script for the >> console >> > and >> > > > then leaves the console open (unless there is a failure in executing >> > the >> > > > script) and the the second executes a script through the >> ScriptExecutor >> > > and >> > > > takes arguments that configure the script. >> > > > >> > > > Both have their uses, but ScriptExecutor and -e are a hold-over from >> > > > TinkerPop 2.x and they introduce a bit of an incongruity where a >> script >> > > > that will run for the first command may not work when used with -e. >> > > > ScriptExecutor is a wrapper for a standalone >> GremlinGroovyScriptEngine >> > > and >> > > > therefore does not allow console commands to be executed. So if your >> > > > exec.groovy contained: >> > > > >> > > > :remote connect tinkerpop.server conf/remote.yaml >> > > > :> 1 + 1 >> > > > >> > > > because you were doing some automation with Gremlin and wanted to >> > > execute a >> > > > remote script, you will get a failure. I think we have a fair bit >> of >> > > room >> > > > for improvement here and as of Groovy 2.4.x there are some changes >> in >> > > > groovysh that will allow us to drop some of our own internal code >> for >> > > doing >> > > > these kinds of things. >> > > > >> > > > I'd basically propose that we: >> > > > >> > > > 1. Deprecate support for ScriptExecutor - it's too confusing to have >> > > these >> > > > scripts execute in different ways through gremlin.sh. >> > > > 2. Deprecate support of bin/gremlin.sh init.groovy (stop encouraging >> > this >> > > > usage pattern) >> > > > 3. Add support for bin/gremlin.sh -i init.groovy which does the same >> > > thing >> > > > as (2) and does not exit the console on failure. That would allow a >> > user >> > > to >> > > > work with their console session up to the point of failure. >> > > > 4. Improve support for bin/gremlin.sh -e exec.groovy to no longer >> use >> > > > ScriptExecutor and execute scripts directly in the console for >> > automation >> > > > purposes. >> > > > 5. Add some other options to control output to the console so that >> you >> > > > could do bin/gremlin.sh -q -e exec.groovy which would execute in a >> > quiet >> > > > mode with no output, for example. >> > > > 6. Groovy's shell lets you do groovysh script1.groovy >> script2.groovy, >> > > > script3.groovy..... We could do something like that too if we >> wanted, >> > but >> > > > we currently allow for something Groovy's shell does not: script >> > > arguments. >> > > > I suppose we could do the multi-file thing and have some syntax for >> > > passing >> > > > command line arguments. maybe like: bin/gremlin.sh -e script1.groovy >> > > > [argument1 argument2] script2.groovy [arg1] - I don't think we >> could do >> > > > this without a breaking change though, so perhaps we worry about >> this >> > for >> > > > 3.3.x whenever we get around to working on that. >> > > > >> > > > I plan to experiment on these changes in the coming days for 3.1.3. >> > > Please >> > > > let me know if there are other thoughts on this matter. >> > > > >> > > >> > >> > >
