epriestley 5e70719306 [Wilds] Continue toward a generalized "arc alias" workflow ... Summary: Ref T13098. This leaves a lot of rough edges but nothing is overtly broken so here's where we're at so far: Config sources get "scopes", like user configuration vs system configuration. The major reason for this is so that `arc set-config x y` can know where it's supposed to write. This is generalized enough that we can implement `arc set-config --system ...` and `arc alias --local ...` and so on relatively easily later, although scopes themselves are not modular (a third-party can't add a new type of config scope). Maybe we'll modularize this some day but it felt like that's probably YAGNI/overboard since we have no current use cases. For now, a source does not need to belong to any particular scope. Config may be writable (like user config in `~/.arcrc`) or nonwritable (like `--config` flags). Writable config can now specify how to write to disk. Config files can actually write to disk now, although the only pathway for doing this that exists is via `arc alias`. Aliases now parse properly and can write to disk. `arc alias` now lets you define aliases, and writes them to disk. **The first time you do this, your `~/.arcrc` file will be rewritten into a format which old `arc` can not read!** It's relatively easily to unmangle/repair these files so I'm planning to just let this happen. When a toolset is invoked, it now reads and evaluates aliases. Aliases have a lot of new guard rails like suggesting the user try `arc draft` if they type `phage draft`, allowing alias chains, detecting cycles, and limiting chain length. Workflows can provide help and argument lists in a more structured way. I've moved this to sub-objects: help is now on `WorkflowInformation` (instead of a bunch of different `getHelp()`, `getSynopsis()` methods) and arguments now have a `WorkflowArgument` object instead of a dictionary. I think this pattern is generally better for extending: it lets us add and change stuff with less impact (and greater explicitness) down the road. `arc alias` now has reasonable help text and argument documentation. The `arc alias` (list) and `arc alias x` (details/remove) flows don't work yet but `arc alias x y` does. `arc liberate` now uses the new help/argument stuff, although the help needs more beef eventually. I pruned a bunch of long-obsolete or questionable flags and renamed `--all` to `--clean` since `--all` sounds like "liberate all libraries", which is now the default behavior of `arc liberate`. Test Plan: You can now define chains of aliases. Finally! ``` $ arc draft4 WARNING Ignoring unrecognized configuration option ("hosts") from source: User Config File (/Users/epriestley/.arcrc). WARNING Ignoring unrecognized configuration option ("load") from source: Project Config File (/Users/epriestley/dev/core/.arcconfig). ALIAS arc draft4 -> arc draft3 ALIAS arc draft3 -> arc draft2 ALIAS arc draft2 -> arc diff Usage Exception: Unrecognized argument '--draft'. ``` This also works now: ``` $ phage alias deploy-secure -- deploy --hosts secure001-4 --limit 1 ``` General! Reviewers: amckinley Reviewed By: amckinley Maniphest Tasks: T13098 Differential Revision: https://secure.phabricator.com/D19697		2018-09-25 15:57:22 -07:00
..
parser	[Wilds] Remove libphutil	2018-09-21 16:38:53 -07:00
xhpast	[Wilds] Remove libphutil	2018-09-21 16:38:53 -07:00
ArcanistRuntime.php	[Wilds] Continue toward a generalized "arc alias" workflow	2018-09-25 15:57:22 -07:00