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
|Open||epriestley||T13490 Upgrade all "classic" Arcanist workflows to Toolsets|
|Resolved||epriestley||T13497 Arc may fail on startup with a error about missing "default" config|
|Open||epriestley||T13544 Modernize the "arc diff" workflow|
- Mentioned In
- rARC8b973bf4390c: Alias newer "--library" to "--load-phutil-library" in legacy workflows
D21323: Alias newer "--library" to "--load-phutil-library" in legacy workflows
T13546: Modernize the "arc land" workflow
T13177: ServiceProfiler integration should be a configurable part of Future, not hard-coded into subclasses (HTTPSFuture, ExecFuture)
- Mentioned Here
- T13488: Upgrading: Early 2020 Changes to Arcanist
D19706: [Wilds] Provide a skeleton for prompt behaviors
D20998: Port "arc get-config", "set-config", and "prompts" to Toolsets
T11968: Decide the fate of FutureGraph
T13500: During startup, guarantee "(string)1.23" is "1.23", not "1,23"
T13507: Compress Conduit client requests
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:
- inspect (new)
These workflows are trivial aliases of feature but still need minor updates:
These workflows were previously modernized:
These workflows still need to be modernized:
- backout (and revert)
- get-config (and set-config)
- start (and stop)
- 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.
These are in better shape now:
These were removed:
That leaves these:
- get-config (and set-config)
- alias (needs work)