Is there work planned to obviate the need for sett...
# general
l
Is there work planned to obviate the need for setting PANTS_CONCURRENT=True in order to run two commands at the same time? Ideally without a performance penalty. I ask because we are starting to roll out pants usage to more of our org, and we are faced with either the annoyance of never running two commands at the same time, or significant performance degradation (for short commands it can be 10x slower to set PANTS_CONCURRENT=True). I don't know enough about pants internals to know how crazy an idea this is, but it would have a big impact on our team.
h
fwiw, this isn't something unique to Pants. Bazel has this same restriction for example.
I think the conventional way of operating is to run one command and let it handle concurrency internally rather than an external caller doing the concurrency.
l
Yeah I get that this might be a hard problem and that others may have taken the same approach. But.... our teammates are not going to compare pants to bazel, they are going to compare
pants test
to
pytest
.
Also, now that filter options are baked into all commands, I rarely hit the case you are talking about.
the cases I have hit today: 1. running tests and trying to commit (which runs pants-based pre-commit) at the same time 2. running more than one of our services at the same time (for dev work)
e
I'm almost positive there is no work currently planned. The tracking issue is old!! https://github.com/pantsbuild/pants/issues/7654
h
For 2, I opt to use pants only for building things and separate tooling (in our case Ansible) for running multiple things
l
Yeah but I would really like to not have to do that.
h
I've never tried it, but can you not do
./pants run
and call out multiple services at a time in one command?
l
good question, I don't know
e
Pretty sure no.
Perhaps this could be done via an experimental shell command gadget? A bit like a hacky docker compose?
A series of
x&; y&; z&; join
l
I can think a of a lot of ways to hack around this.
I am trying to figure out if someone is interested in fixing the core issue. 🙂 I would but it would take me awhile to get up to speed on the internals.
e
Interested is not your problem I think. Having time is.
l
ha ok. then maybe I am trying to agitate for priority 🙂
h
I don't think anyone would object to this being done, it's a question of prioritization 🙂