Pants should release it's lock on run targets

[kuza55]

Is your feature request related to a problem? Please describe.
pants run is a convenient way to run a single command, but pants continues to holding some sort of lock when running, necessitating passing PANTS_CONCURRENT.

Describe the solution you'd like
Pants should finish up the processing needed to release the lock and then do so when it starts executing run commands so that subsequent pants commands can be run without concern.

Describe alternatives you've considered
pants package && ./dist/.... is a workable alternative, but somewhat defeats the point of the run target.

[cburroughs]

See also #7654

[huonw]

Sorry for the trouble!

#7654 is the "root cause", but there's an extra subtlety here: pants run ... can restart if its inputs change (for some targets), and doing that definitely requires being engaged with the "usual" systems/locks to have the file-system monitoring and potential running of arbitrary code-generation targets too.

[kuza55]

there's an extra subtlety here: pants run ... can restart if its inputs change (for some targets)

This is certainly not behaviour that I want from pants. Restarting on changes is a reasonable way to ensure that pants does not get inconsistent snapshots of code while running builds, but once a build has been completed, I do not have any desire for pants to decide to rebuild and re-run code.

[huonw]

Yeah, I think there's two distinct styles of "running a target":

1. run some development server or similar that is nice to be restarted as code changes (some targets can opt-in via restartable=True fields)
2. build an artifact and run it, independent of any future code changes

Both seem to be useful at different times. For instance, in my work repo, 1 is very valuable for exactly running an API server, it'd be a non-starter for the usual dev workflow to have to remember to go restart it manually on every change or git pull.

The only way to get behaviour 1 is with some long-running pants invocation, like the current behaviour of pants run. A workaround for 2 is to do the pants package ... && ./dist/... dance you identified.

Even without #7654, Pants could be more intelligent: if a pants run target isn't restartable anyway, have Pants itself "quit" and just let the process do its thing independently.

Pants is entirely volunteer driven. Is this something you're interested in implementing? If so, please feel free to drop into the #development channel on slack or ask for guidance here.

[kuza55]

I'm unlikely to find cycles for any significant development on pants for a long time.

It might be helpful to outline what the simplest solution to having pants work for use case number 2 would look like in case it is easy enough for me to find some cycles or in case someone else wants to take this up.

[vin]

I think you're right that they're different behaviors with different expectations. Maybe the restarting behavior could be requested by invoking with --loop: https://www.pantsbuild.org/2.21/reference/global-options#loop ?

[benjyw]

It would be useful to have Pants launch a run process that it detaches from and forgets about, with no file watching etc. We would benefit from this in our own release process: #21081

[benjyw]

I think you're right that they're different behaviors with different expectations. Maybe the restarting behavior could be requested by invoking with --loop: https://www.pantsbuild.org/2.21/reference/global-options#loop ?

Yes, I think that is closer to the expected behavior. Without --loop Pants should fire-and-forget the run process.