[DISCUSS] Gremlin Console init and executor

[Stephen Mallette <sp...@gmail.com>]

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.

Re: [DISCUSS] Gremlin Console init and executor

[Stephen Mallette <sp...@gmail.com>]

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 <sp...@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 <pl...@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 <sp...@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 <pl...@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 <
>> spmallette@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.
>> > > >
>> > >
>> >
>>
>
>

Re: [DISCUSS] Gremlin Console init and executor

[Stephen Mallette <sp...@gmail.com>]

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 <pl...@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 <sp...@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 <pl...@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 <
> spmallette@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.
> > > >
> > >
> >
>

Re: [DISCUSS] Gremlin Console init and executor

[Jason Plurad <pl...@gmail.com>]

> 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 <sp...@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 <pl...@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 <sp...@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.
> > >
> >
>

Re: [DISCUSS] Gremlin Console init and executor

[Stephen Mallette <sp...@gmail.com>]

> 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 <pl...@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 <sp...@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.
> >
>

Re: [DISCUSS] Gremlin Console init and executor

[Jason Plurad <pl...@gmail.com>]

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

Re: [DISCUSS] Gremlin Console init and executor

[Stephen Mallette <sp...@gmail.com>]

Yeah - I think -e should still exit with an error code.

On Mon, Apr 18, 2016 at 1:33 AM, Daniel Kuppitz <me...@gremlin.guru> wrote:

> I've seen a few projects where it was preferred that the console exits
> after processing the script (script were triggered via nightly cron jobs).
> So just for clarification - is that what -e will (continue to) do in the
> future (also in case of errors in the script) or do we have to add an
> explicit System.exit() (but then what about errors in the script)?
>
> Cheers,
> Daniel
>
> On Sun, Apr 17, 2016 at 3:35 PM, Stephen Mallette <sp...@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.
> >
>

Re: [DISCUSS] Gremlin Console init and executor

[Daniel Kuppitz <me...@gremlin.guru>]

I've seen a few projects where it was preferred that the console exits
after processing the script (script were triggered via nightly cron jobs).
So just for clarification - is that what -e will (continue to) do in the
future (also in case of errors in the script) or do we have to add an
explicit System.exit() (but then what about errors in the script)?

Cheers,
Daniel

On Sun, Apr 17, 2016 at 3:35 PM, Stephen Mallette <sp...@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.
>