Page MenuHomePhabricator

Consider an "arc prompts" or similar, to improve automation on top of "arc"
Closed, ResolvedPublic

Description

In theory, "arc" is user-facing only and not an API.

In practice, this is often untrue, and arc unit --target ..., arc call-conduit, arc --conduit-token ... are all "blessed" use cases which pretty clearly make arc an API.

One issue with this is that we have a lot of advisory/guardrail prompts which API callers would probably like to always ignore. Some commands have a --force, but this generally does not skip every prompt, and callers don't necessarily want it to skip every prompt.

I'd like to standardize how workflows prompt users, and realistically consider API callers in the design. Some possibilities include:

--no-guardrails: Separate prompts into "guardrail" prompts and "actually important" prompts, and let callers disable the advisory ones. Possibly, disable the advisory ones automatically if stdout is not a TTY. I don't like this because the bucketing is pretty arbitrary, there are almost certainly prompts which don't fit cleanly into either bucket, and I doubt it really gives us much traction against this.

Just make --force skip every prompt: give users enough rope to shoot themselves in the foot. But some prompts have super awful consequences and I don't actually trust users to use this kind of power responsibly, e.g. see the giant red skull on bin/remove destroy.

Plumbing/porcelain: Say that the "API" is either separate plumbing commands (arc repository-amend) or that you have to write a workflow and call the API yourself. Separating commands likely means some checks are slow/late (if they occur in the wrapped plumbing workflow) or some checks are duplicated (if they occur in both so that the command can fail quickly). I'd also like to make "write a workflow" easier, but: don't believe most users will do it; and don't necessarily want the entire internal API to realllly be API surface area -- we should still be able to stick a giant "caution, advanced" sticker on extension development.

Enumerate every prompt: I haven't really talked myself into this yet, but we could enumerate every prompt and let callers pre-respond. An arc prompts <workflow> could list all possible prompts. Configuration could let interactive users pre-respond, too. Advantages to this include that it's explicit, works for interactive use cases, and would let us get rid of a lot of --ignore-x, --allow-y type flags.

Event Timeline

epriestley triaged this task as Normal priority.Sep 10 2018, 3:24 PM
epriestley created this task.

See also PHI862 for a request for arc amend --force.

Use cases we've seen FWIW:

  • When we tried to write an extension within an IDE to allow people to "push a button and put your diff up", it turned out to be easier / less messy to rewrite the parts of arc diff we needed in javascript than it was to try to shell out to it
  • Actually now that I think about it, all other use cases are some variation of someone wanting to shell out to arc diff and automate it

D19706 begins to provide for this. I'm just going to roll the rest of it into T13098 since most further changes are likely to be entangled.

begins to provide for this

Specifically, it takes us down the arc prompts / enumerate every prompt route.