--error does not suppress new batch mode warning in 0.13.15
#3091
Comments
SethTisue
changed the title
--error does not suppress new batch mode warning--error does not suppress new batch mode warning in 0.13.15
|
also |
|
The primary reason this is happening is because I'm trying to do it as early as possible, when there is a clear distinction between sbt.xMain, and sbt.ScriptMain or sbt.ConsoleMain - ironically exactly for scripting reasons. I think I can rework this to appease both use cases, but I wonder: @SethTisue what's the severity in your mind of this regression? |
|
Is it possible to disable this warning @dwijnand? For instance, I use sbt for scripting intensively. I think that this warning is good when the user types sbt, but I'd like to remove it when I'm programmatically controlling sbt. |
|
By invoke sbt in non-interactive (aka batch) mode. The easiest way is by appending sbt compile < /dev/nullOr in sbt-extras by passing sbt -batch compileI'm happy to revise the implementation to strike a better balance. |
|
Thanks for the pointers. It would be interesting to have something like |
|
The concept of "script" already refers to http://www.scala-sbt.org/0.13/docs/Scripts.html (and its sbt.ScriptMain), which is not what you're after when you say "script".. :-/ |
|
It's a pity that sbt is using that definition of 'script' when the widely used notion of scripting is substantially different (for example, bash scripts). In any case, |
|
The nomenclature looks consistent to me: a bash script is a script that bash interprets and an sbt script is a script that sbt interprets (using ScriptMain). I'd be happy to port |
You're right.
I would like to see this supported by default, so 👍 . |
|
If we implement the |
|
Indeed that was my idea. I'm just not sure what priority to give this regression - i.e if it should be worked on now. |
|
We can schedule it for next 0.13.x release, but I don't think it's high priority enough to disrupt the current iteration. |
|
|
|
This really shouldn't be a warning: it shows up even in things like I personally think this was an ill-advised feature. You do this in the docs, not as nagware. I already have a mother, I don't need my build system to scold me—especially if its message is that I'm supposed to change my workflow and keep a JVM around permanently. Tools are supposed to make my life easier, not the other way around. |
|
Agree 100% with @sarahgerweck. This warning is just plain annoying and not very reliable. |
|
Due to JIT (and startup time of sbt itself too I assume), there's a significant difference in compiler performance if you keep the sbt shell around, so I think it warrants displaying a message to let people know that running batch mode is slower. Here are the some changes I suggest:
|
|
i too find this new batch mode warning annoying. not so much the warning itself (i can live with the extra text) but the fact that by accident hitting [ENTER] puts me in interactive mode. this makes batch/scripting usage more difficult as others have mentioned before me. |
Specifically: * Make them both commands, so they run after early commands (--error). * Make notifyUsersAboutShell aware of "iflast shell" instead of "boot". * Make writeSbtShell use a logger and tweak the message Refs sbt#3091
This requires moving the notification to after LoadProject, so much later in time, sadly.. Refs sbt#3091
This is a change in strategy. The motivation is the need to find a good balance between: + informing the uninformed that would benefit from this information, & + not spamming the already informed Making it dependent on "compile" being present in remainingCommands will probably make it trigger for, for example, Maven users who are used to running "mvn compile" and always run "sbt compile", and who therefore are unneccesarily suffering terribly slow compile speeds by starting up the jvm and sbt every time. Fixes sbt#3091
In sbt 0.13.15, in addition to notifying the user about the existence of
sbt's shell, a feature was added to allow the user to switch to sbt's
shell - a more pro-active approach to just displaying a message.
Unfortunately sbt is often unintentionally invoked in shell scripts in
"interactive mode" when no interaction is expected by, for exmaple,
invoking `sbt package` instead of `sbt package < /dev/null`. In that
case hitting [ENTER] would silently trigger sbt to run its shell,
easily wrecking the script. In addition to that I was unhappy with the
implementation as it created a tight coupling between sbt's command
processing abstraction to sbt's shell command.
If you want to stay in sbt's shell after running a task like `package`
then invoke sbt like so:
sbt package shell
Fixes sbt#3091
|
@koertkuipers thanks for your feedback. I've opened #3153 to remove the [ENTER] feature, targeting sbt 0.13.16. |
In sbt 0.13.15, in addition to notifying the user about the existence of
sbt's shell, a feature was added to allow the user to switch to sbt's
shell - a more pro-active approach to just displaying a message.
Unfortunately sbt is often unintentionally invoked in shell scripts in
"interactive mode" when no interaction is expected by, for exmaple,
invoking `sbt package` instead of `sbt package < /dev/null`. In that
case hitting [ENTER] would silently trigger sbt to run its shell,
easily wrecking the script. In addition to that I was unhappy with the
implementation as it created a tight coupling between sbt's command
processing abstraction to sbt's shell command.
If you want to stay in sbt's shell after running a task like `package`
then invoke sbt like so:
sbt package shell
Fixes sbt#3091
This is a change in strategy. The motivation is the need to find a good balance between: + informing the uninformed that would benefit from this information, & + not spamming the already informed Making it dependent on "compile" being present in remainingCommands will probably make it trigger for, for example, Maven users who are used to running "mvn compile" and always run "sbt compile", and who therefore are unneccesarily suffering terribly slow compile speeds by starting up the jvm and sbt every time. Fixes sbt#3091 Fixes sbt#3097
In sbt 0.13.15, in addition to notifying the user about the existence of
sbt's shell, a feature was added to allow the user to switch to sbt's
shell - a more pro-active approach to just displaying a message.
Unfortunately sbt is often unintentionally invoked in shell scripts in
"interactive mode" when no interaction is expected by, for exmaple,
invoking `sbt package` instead of `sbt package < /dev/null`. In that
case hitting [ENTER] would silently trigger sbt to run its shell,
easily wrecking the script. In addition to that I was unhappy with the
implementation as it created a tight coupling between sbt's command
processing abstraction to sbt's shell command.
If you want to stay in sbt's shell after running a task like `package`
then invoke sbt like so:
sbt package shell
Fixes sbt#3091
this regresses on #840
The text was updated successfully, but these errors were encountered: