Page MenuHomePhabricator

Upgrade all "classic" Arcanist workflows to Toolsets
Open, NormalPublic

Description

This is just a place for me to stick things while I clean up the mess I made merging the wilds and experimental branches into master.

Revisions and Commits

Restricted Differential Revision
rARC Arcanist
D21113
D21104
D21101
D21100
D21099
D21098
D21097
D21096
D21095
D21094
D21093
D21092
D21091
D21090
D21089
D21088
D21087
D21086
D21085
D21075
D21074
D21060
D21030
D21029
D21025
D21024
D21006
D21005
D21004
D21002
D21001
rP Phabricator
D21105
D21102

Event Timeline

epriestley triaged this task as Normal priority.Feb 15 2020, 2:50 AM
epriestley created this task.
epriestley added a revision: Restricted Differential Revision.Feb 23 2020, 1:16 AM
epriestley added a commit: Restricted Diffusion Commit.Feb 23 2020, 1:17 AM

T11968 was a very deep hole, but I think I've now dug my way out of it. With those changes, these workflows are now modern:

  • browse
  • feature
  • inspect (new)

These workflows are trivial aliases of feature but still need minor updates:

  • branch
  • bookmark

These workflows were previously modernized:

  • alias
  • anoid
  • help
  • liberate
  • shell-complete
  • upgrade
  • upload
  • version
  • weld

These workflows still need to be modernized:

  • amend
  • backout (and revert)
  • call-conduit
  • close-revision
  • close
  • commit
  • cover
  • diff
  • download
  • export
  • flag
  • get-config (and set-config)
  • install-certificate
  • land
  • linters
  • lint
  • list
  • paste
  • patch
  • start (and stop)
  • tasks
  • time
  • todo
  • unit
  • which
  • alias needs significantly more work.

Many of these are probably not that bad, but there are still some cross-cutting concerns:

  • A fair amount of stuff depends on get-config and set-config.
  • A fair amount of stuff depends or should depend on new "prompt" infrastructure outlined in D19706. The "prompt" stuff also depends on config.
  • I took a stab at config in D20998 but I think a more cautious approach may be required.
  • T13500 (and possibly T13507) desire some kind of config area that behaves like a cache rather than a config file.

I think this is all tractable, just not entirely straightforward.

Separately, lint and unit in wilds have had a ton of work done, but this may not need to come over immediately.

In any case, I think tackling config + prompt stuff is next.

A general issue with config is that I'd like to modularize config sources, so you can read config from a service or something if you really want, or define a custom configuration source for other Toolset commands like phage. Previously, sources were hard-coded.

There are a large number of configuration sources in arc by default:

defaults: Builtin default value for a setting.
local: Config file specified with `--config-file`.
project: Config in `.arcconfig`.
runtime: Config specified with `--config x=y`.
system: Global `/etc/arcconfig`.
user: Config file `~/.arcconfig`.
working-copy: Config in `.git/arc/config` or similar.

Broadly, the cross-cutting concern here is that configuration options are modular and configuration sources are also modular, and there's no reasonable general way for a configuration option to define a method like canInteractWith(ConfigurationSource $source), nor for a configuration source to define a method like canBeInteractedWithBy(ConfigurationOption $option): neither side can really describe what they should do with an arbitrary third-party object of the other type.

I think the only real path forward is to give sources and options various attributes and try to cover as much ground as possible:

Source->supportsToolset(): Some of these may not make sense for all toolsets (for example, phage probably shouldn't load .git/arc/config).

Source->isTrusted() / Option->isSafe(): I'm also increasingly looking at the security model of these configuration files. Currently, arc has a security model like make: if you run it in a working copy, you're trusting the code in the working copy. I think this is generally reasonable for end-users, but perhaps less reasonable for build automation.

"Unsafe" options are things that cause libraries to load, shell code to execute, etc. So many options are "unsafe" that this may not really make much sense, or the concept may need to be narrower like "safe for automation".

Source->isPrivate() / Option->isPrivate(): Another issue is privacy. We'd prefer not to write credentials into (or read credentials from) .arcconfig, since it's public.

Source->isWritable(): Another issue is writability. We can't write into runtime config (--config x=y) and probably (?) shouldn't write into local config (--config-file) -- or if we do, it shouldn't be with an overloaded flag.

I think I'm going to remove these workflows outright:

  • backout/revert
  • close
  • flag
  • start
  • stop
  • time

I'll provide more rationale in T13488.

These are in better shape now:

  • amend
  • branch
  • bookmark
  • call-conduit
  • download
  • prompts

These were removed:

  • backout
  • revert
  • close
  • flag
  • start
  • stop
  • time

That leaves these:

  • close-revision
  • commit
  • cover
  • diff
  • export
  • get-config (and set-config)
  • install-certificate
  • land
  • linters
  • lint
  • list
  • patch
  • paste
  • tasks
  • todo
  • unit
  • which
  • alias (needs work)