Is there a reason why pants' limit on concurrent r...
# general
l
Is there a reason why pants' limit on concurrent runs applies to the
help
command?
h
Good question, Stu would know best and is out today. but my limited understanding is that we might be able to work around that; I think
help
early exits Would you be willing to open a ticket? https://github.com/pantsbuild/pants/issues/new/choose If it's not very easy to do, the answer would likely be to lean into https://github.com/pantsbuild/pants/issues/7654
l
Copy code
$ ./pants help-advanced export
Another pants invocation is running. Will wait up to 60.0 seconds for it to finish before giving up.
If you don't want to wait for the first run to finish, please press Ctrl-C and run this command with PANTS_CONCURRENT=True in the environment.
also concurrent runs would be hugely helpful for us, esp as folks would like to have more than one
./pants run
going at the same time for dev work
💯 1
🙌 1
h
+1, I wish it got more votes in the 2022 survey. Altho as explained at https://blog.pantsbuild.org/the-2022-annual-community-survey-is-a-wrap-and-the-results-are-in/ the votes aren't literal gospel and maintainers may prioritize things like this
s
@loud-laptop-17949 we’re using multiple processes using
PANTS_CONCURRENT=True
. You can enable this via
pants.toml
as mentioned here: https://www.pantsbuild.org/docs/reference-global#section-concurrent
w
setting
--concurrent
will disable
pantsd
, so you should probably not set it globally in your repository. it’s intended more as a localized “please run this command concurrently” flag, rather than something that you put in
pants.toml
sorry for the confusion there: the end goal is to deprecate the
--concurrent
flag by allowing concurrent runs, but we wanted something with a different semantic meaning than
--no-pantsd
, so that users could track why they were skipping pantsd.
1
🔼 3