Is there anything to be done about general slowness on startup of the

pants

command? Maybe there are some best practices I'm missing, but even on my trivial demo repository it can take upwards of 7 seconds to start doing anything (apparently, maybe Im just missing some verbosity flags?)

that’s ~normal startup time for the pants daemon.. subsequent runs after that should be significantly faster… until some configuration change invalidates pantsd and it needs to restart.

Do you set the

concurrent

or

pantsd

flags in

pants.toml

?

Yes to `concurrent`; no to

pantsd

Ah, okay. The

concurrent

flag unfortunately also disables the pants daemon, which means you have to pay the initialisation cost on every start up. If you can remove it, that’ll make subsequent runs much faster. You can set it for specific long running commands (eg running a server) with

PANTS_CONCURRENT=true pants run …

or

pants --concurrent run …

. It is a bit annoying. If you want a bug to subscribe to, https://github.com/pantsbuild/pants/issues/7654 is it.

Ahhh ok thank you!

Unfortunately no

Im guessing that doesn't cleanly map to some kind of model Im unfamiliar with, but I think thats essentially what I'm after. Some targets that are run-able are long running and everything else should run without concurrency

yeah, now that you point it out, my internal repo has exactly the same structure. We have some external orchestration that invokes pants for those long running things, that sets that option. I guess (haven't tried yet) one could do an alias like: https://www.pantsbuild.org/docs/reference-cli

[cli]
run-the-server = "--concurrent run path/to:server"

And then one runs

pants run-the-server

and it might do the right thing?