aloof-angle-91616
02/22/2019, 5:45 PMprocess_executor
executing processes, and that uses grpc i think, and wouldn't it be neat if we could use that directly or indirectly as the pantsd thin client itself?" -- as in, (hand waving) move most of the logic that is done in remote_pants_runner.py
into daemon_pants_runner.py
and just send over the arguments?
i personally think since we already have defined an extension of nailgun which we support on both the front and back end, it seems like it might not be an awful protocol to continue to use (i personally found it not too hard to extend and formalize in https://github.com/pantsbuild/pants/pull/6579), although @average-vr-56795 reports that the canonical implementation (NGServer
and the ng.c
client) is often flaky. afaik process_executor
just gets all of the process output at once instead of streaming like e.g. nailgun supports, so i'd think we would not use the bazel remote execution api for executing pants itself anyway, and it seems like it would be an unnecessary earth-scorching to drop the nailgun protocol for this use unless there's an off-the-shelf alternative.
it's also extremely possible (working to disprove this) that native-image might actually approach nailgun performance enough locally for us to just drop persistent process management with nailgun entirely, which would be a ridiculous amount of code we could delete if native-image ends up very reliably building jvm code. we would still want some support for persistent processes when we get to things like lsp/bsp servers (discussed in https://github.com/pantsbuild/pants/issues/7079).