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. > > > > > > > > > >
