I don't understand all the details of how that works because it's handled in

termion

, but certainly if pantsd was written withthe assumption that it would capture stdout/stderr and send it to the client, that would wreck havoc with anything trying to grab the tty in raw mode, which is exactly what the v2 UI does

the v2 UI code is already in rust

basically right now v2 pantsd spits out an ugly error message coming from

termion

unless --no-v2-ui is passed

and in general I don't think there's a way to get the v2 UI output when pantsd is running

unless pantsd instead sent something besides curses input to the client, which the client could then interpret into the same --v2-ui

as a first step I think it makes sense to just hardcode the fact that v2_ui can't be enabled if

is_daemon

is true in

LocalPantsRunner

yeah on a long term basis it makes sense that pantsd should send some abstract data structure representing the progress of a run to the client, which renders it

but that sounds like a fairly big redesign

isn't the whole point of Nailgun to send stdout/stderr around?

we can still send things over stdout/stderr

changing the communication wire protocol would probably be a big design but converting stdout into lines of json or protobuf dooesn't seem absurd

i didn't realize it was already in rust -- that's why i think this is feasible

I think that right now we have to consider the case of v2-ui + pantsd to be broken

the way the v2 UI is architected, it won't work without modification if pantsd tries to run it, because there's no raw terminal for it to hook up

and if we only ran the v2 UI in the client part of the code, we'd have to rewrite a bunch of things about how the engine talks to it

which we could potentially do if we're gonna rewrite the pantsd client anyway

i think that all sounds correct

this would be fun to look at for twitter hackweek next week but i've got other plans this exact moment

okay I actually am seeing the v2 UI locally - I think earlier I was running against a warm pantsd so I missed it

but I"m not sure where this is executing

prepare_v1_graph_run_v2

is looking for the v2_ui option, so maybe there? but I don't expect the v2 UI to work in the daemon

re: https://www.pantsbuild.org/architecture_pantsd.html , does this document describe how pantsd currently works, or how pantsd used to work before threading was removed?

it seems like the latter from the text?

yes, the latter :( wish we’d updated docs

Are you all able to share the rearchitecture docs with Toolchain? I believe they were internal to Twitter

that’s news to me. @average-vr-56795 are you familiar with any such pantsd architecture docs?

Iirc there was a doc about removing forking. I don’t know if we ever shared that with Toolchain. I think this was in the Fall

ok, i’ll try to find that

this is the closest thing i can find: https://github.com/pantsbuild/pants/issues/7390#issuecomment-476289549

has anyone seen this before?

❯ cargo check
    Updating git repository `<https://github.com/pantsbuild/rust-protobuf>`
error: failed to resolve patches for `<https://github.com/rust-lang/crates.io-index>`

Caused by:
  failed to load source for a dependency on `protobuf`

Caused by:
  Unable to update <https://github.com/pantsbuild/rust-protobuf?rev=171611c33ec92f07e1b7107327f6d0139a7afebf#171611c3>

Caused by:
  failed to fetch into /Users/hfuller/.cargo/git/db/rust-protobuf-8e8a2cd87e934b3d

Caused by:
  object not found - no match for id (acc84d088d46ca911b8d081ab2e4906e63448300); class=Odb (9); code=NotFound (-3)