and then DaemonExiter overloads that

for DaemonPantsRunner

and there's alos a LocalExiter for LocalPantsRunner, but DaemonPantsRunner uses LocalPantsRunner internally

because we want to make sure we clean up the state of a single pants run from the daemon, which is different than the cleanup we need to do for a single pants run without the daemon

it's also different than the cleanup we need to do when killing pantsd and it's different than the cleanup we need to do when killing the pailgun client

the exiters also follow the prototype pattern and can call each other as you noted

@hundreds-father-404: i seem to remember that you had gotten a better error message from the sudden abort on the remoting shards...?

indeed! https://github.com/pantsbuild/pants/issues/9395#issuecomment-604842797

literally just that single line, but at least it’s something

@witty-crayon-22786 @dry-policeman-7927 @red-balloon-89377 @fancy-motherboard-24956 @average-vr-56795 @hundreds-breakfast-49010 would it be at all useful if i looked at trying to port pants to the

tracing

crate (https://github.com/tokio-rs/tracing) to make it easier to define v2 workunit spans in rust? we could even spawn a zipkin span for every single method call if we wanted to, as well as every hop across the FFI boundary. the github page has a few examples describing why we might want to do this. the

tracing

crate also decouples creating spans and logging those spans, where logging is delegated too a

tracing::Subscriber

. the two parts this needs are: (1) to port to the

tracing

crate, which i've started (a while ago) here: https://github.com/pantsbuild/pants/pull/7395 (2) to implement a

tracing::Subscriber

for zipkin, which i've mostly done here: https://github.com/cosmicexplorer/learning-progress-bar/blob/master/zipkin/src/lib.rs, and can upstream in a separate PR

I think @hundreds-breakfast-49010 has some thoughts here

Hm,

./v2 fmt

is not terminating (or maybe just taking over a minute) in the

fmt

stage, meaning after all the formatters have run and write to the build root. It was also taking 100% of my CPU according to

top

. I didn’t notice this on Friday. Maybe the tokio upgrade has something to do with it?

Is it okay if I pull the trigger on merging this so I can rebase on it? https://github.com/pantsbuild/pants/pull/9477

I think Stu would be fine with that. Please do

hey folks: if anyone sees silent failures on the remoting shards, please ping https://github.com/pantsbuild/pants/issues/9395

@hundreds-father-404 I just ran into a fun filespecs thing…

Hey, what’s the story on using a non-Python binary like

Docker

with V2? @wonderful-iron-54019 and I started writing a

docker-build

plugin that wraps the command

docker build

, and we took the naive approach of assuming that

docker

is already installed on the system. Is that the right approach? We do that already with assuming that

/usr/bin/perl

and

python

are installed on the system.

i would really like to have a wrapper rule that converts e.g.

LocalOnlyProcessExecuteRequest

=> an

ExecuteProcessRequest

with

env={'PATH': os.environ['PATH']

so that we can be explicit about when we do this and track how many are remaining

Generally, how do we expect to handle it? For example, I can’t imagine us ever wanting to try to install the Docker CLI through Pants. I don’t even think it would be possible (needs sudo permissions)

it has a daemon.

yes, i would love to have pants install it automatically but for now i think relying on a local install is a good solution

one approach would be to encapsulate the usage of docker as something that will run in the

@goal_rule

using interactive process.

Right now, it’s encapsulated in a

@goal_rule

but uses

ExecuteProcessRequest

I think as long as we give a good error message if we can't find the

docker

binary

it's fine

We could also verify the docker version against an expected semver constraint in pants.toml

To improve hermeticity somewhat

we validate the gcc version in the native backend for osx where gcc doesn’t work yet

i really wanna get back to the v2 native backend soon

Do we expect

--ignore-pants-warning

to apply at import time of plugins? Using

deprecated_module

on something like

contrib/avro/register.py

won’t work with

--ignore-pants-warning

because we haven’t yet called

logging.py:setup_logging()