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