Running multiple bazel processes

[Paul Gross]

Is there a way to run more than one long running process with `bazel run`? The error I get is "Another Bazel command is running (pid = 29113). Waiting for it to complete..."

My use case is running several long running servers so I can test the interactions between them. Ideally, I'd like to `baze run server1` and `bazel run server2` in different windows.

My current workaround is to use something like `bazel build server1 && ./bazel-bin/server1` so I don't actually run it through bazel.

Thanks,
Paul

[Damien Martin-guillerez]

AFAIK there is no way to do it simply because bazel run attach the output of the command to the output of the bazel client. Anyway, running outside of Bazel is correct. Do you have an issue with it, or is it just less convenient?

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/099e24dc-4f76-4b75-b2ab-01e8c377e5b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Damien

[Paul Gross]

I don't have an issue with it. It's just less convenient. 

Thanks,

Paul

[jason gessner]

perhaps a bazel launch command to build and launch, but not attach (or a --detach option to run?).  it is definitely nice to build something that isn't built and let bazel kick it off rather than building and then doing ./bazel-bin/foo/bar.

[Han-Wen Nienhuys]

There is an option to generate a launch script. Does that help?

--script_path (a path; default: see description)
If set, write a shell script to the given file which invokes the target. If
this option is set, the target is not run from %{product}. Use '%{product}
run --script_path=foo //foo && foo' to invoke target '//foo' This differs
from '%{product} run //foo' in that the %{product} lock is released and the
executable is connected to the terminal's stdin.

> --
> You received this message because you are subscribed to the Google Groups
> "bazel-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bazel-discus...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bazel-discuss/aff71d61-2f81-4f12-8a6c-32118055f29c%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

Han-Wen Nienhuys
Google Munich
han...@google.com

[Paul Gross]

Is the main advantage here that you don't have to reach into bazel-bin directly to run the program? Or are there other advantages?

Thanks,

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAFQ2z_OQkXWY8SJk3yVapMsNjTzhUhuEVrnzLqyPDmrEYuTq%3Dg%40mail.gmail.com.

[jason gessner]

On Friday, May 29, 2015 at 11:02:11 PM UTC-5, Paul Gross wrote:

Is the main advantage here that you don't have to reach into bazel-bin directly to run the program? Or are there other advantages?

I find that i often want to run something from my client.  If i make the mistake of using "bazel run" (because i haven't built recently) then I have locked up my client from any other bazel commands.  I'm not sure what the advantage of having bazel hold onto that invoked process is.  I've never wanted that, but I assume there is a reasonable reason.  :)

-jason

[Paul Gross]

I mean is there an advantage of:

"bazel run --script_path foo //foo && foo"
vs
"bazel build //foo && ./bazel-bin/foo"

It seems like they execute the same thing. The only advantage I see is that you don't have to know the bazel-bin path for the first one.

--

You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/7b654351-7bfc-40c9-a694-f21278239b2a%40googlegroups.com.

[jason gessner]

On Monday, June 1, 2015 at 10:44:38 PM UTC-5, Paul Gross wrote:

I mean is there an advantage of:

"bazel run --script_path foo //foo && foo"
vs
"bazel build //foo && ./bazel-bin/foo"

It seems like they execute the same thing. The only advantage I see is that you don't have to know the bazel-bin path for the first one.

The binary will be executed in both cases, but in the former case you now have a new file called foo in your workspace that you will possibly (probably?) want to delete.  Also bazel run //foo is more compact than either of those options.  :)

It really isn't a big deal.  I'm mostly curious why bazel's existing behavior is to lock up a client if you use bazel run. I'm sure there was a reason at some point, but the behavior has never been what I wanted.  Perhaps I am unusual in this regard, though.

-jason

[Han-Wen Nienhuys]

Every Bazel command, except for "help", locks the client; there is no
special casing for run. Since most people want to continue running
bazel while they are executing an artifact, the bazel --script_path
makes that a little easier.

>
> -jason

[Dan Fabulich]

I was just bit by this issue; I wanted to "bazel run" two long-running scripts at once.

There is one important convenience that --script_path offers: when you're using runfiles with "bazel run //foo", the foo script's working directory is bazel-bin/foo/foo.runfiles, so executing the script with ./bazel-bin/foo/foo has the wrong working directory, missing the runfiles. When you use --script_path, the generated two-line script first does a cd to the correct runfiles directory and then runs the script.

But the generated script includes absolute paths, including platform-specific paths, so the --script_path script can't be checked in. We already .gitignore bazel-*, so we created a "bazel-scripts" directory as a convention.

So we're developing a wrapper script like this:

    mkdir -p bazel-scripts

    bazel run --script_path bazel-scripts/foo //foo

    bazel-scripts/foo

But, not to whine, but that is quite a bit of boilerplate just to run a script without a lock. I wish I could just "bazel spawn //foo" and have it DTRT, locking the client until the script was generated, then releasing the lock to run the script. Or "bazel run --nolock //foo"

Would a PR be considered to add something like this?

[Damien Martin-guillerez]

bazel run --nolock is not a bad idea per se but it is not possible with the current way bazel works.

There are change going on that will allow it but it will take some time before it lands.

[Kristina Chodorow]

FWIW, we have a wrapper script for this:

https://github.com/bazelbuild/bazel/blob/master/scripts/bazel-run.sh

Not as good as having `bazel run` not lock, but might be nicer than rolling your own.

--

You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAN3hOS8AUmRMqMzF9dG16A4o1R%3DzyY6j8xxLmSf66ngh3q9K9A%40mail.gmail.com.