How would you scope APPIUM_HOME when several Appium suites share one machine?

## What `APPIUM_HOME` actually scopes `APPIUM_HOME` is an environment variable naming the directory where Appium keeps installed extensions and the `extensions.yaml` manifest that lists them. It defaults to `~/.appium`. Everything about the extension set is scoped to it: which drivers exist, which versions they are, and where each came from. It scopes nothing else. The Android SDK tooling the **Android** drivers shell out to, and the Xcode installation the **Apple-platform** XCUITest driver needs to build its on-device agent, are host-wide and untouched by this variable. So the question 'where should `APPIUM_HOME` point?' is really 'what is the unit that owns a driver set?' - a machine, a suite, or a driver version. ## What the default implies With the default, the driver set is a property of the **user account** on the machine, which is invisible ambient state: - Anyone who runs `appium driver install` changes it for every suite on that account. - One `appium driver update uiautomator2` silently moves every **Android** suite on the box to a new driver. - Nothing in a suite's own files records which driver versions it ran against. - A second suite that needs a different version of the same driver has nowhere to put it. One shared home is still the right answer for a laptop with one suite on it. It stops being the right answer the moment two suites can disagree. ## The two shapes worth considering | | One shared home (the default) | A home per suite or workspace | |---|---|---| | Driver versions | one set for everything on the account | independent per suite | | Install cost | installed once | a real install per home | | Disk | one copy | one copy per home | | Blast radius of an update | every suite on the machine | the suite you were working on | | Discoverability | you have to remember | the variable sits where the suite starts | A third shape - a home per driver **version**, selected by the variable at start time - is worth knowing for a fleet that must run an old and a new driver side by side. It is an operations answer rather than a project one, and it pays for itself only when the version skew is real rather than anticipated. ## The rules that make either choice survivable 1. Set the variable for **both** the install and the server start. A driver installed into one home is invisible to a server started against another, and the resulting failure names capabilities rather than directories, so it reads as a missing driver instead of a misdirected one. 2. Make the install repeatable. A short script of `appium driver install` commands with pinned versions is the difference between an environment you can rebuild and one you can only inherit. 3. Verify against the home the server will actually use, with `appium driver list --installed`, not against whatever your shell defaults to. 4. Decide who may run `appium driver update` on a shared home, and when. On a shared home an update is a behaviour change for every suite that home serves. ## Deciding The inputs that actually move this decision: - **Do two suites need different driver versions?** If yes, separate homes; nothing else solves it. - **Does the machine belong to one person or to a team?** Shared machines make ambient state expensive, because whoever changes it is rarely whoever discovers it. - **How often is the machine rebuilt?** A home you can recreate from a script cares much less which shape you picked. - **Do the platforms move independently?** The **Android** and **Apple-platform** drivers are separate packages on separate cadences, so a suite may need to hold one back while the other moves forward. For a single **library loan-renewal** suite owned by one team, the default home plus a pinned install script is usually enough. The extra homes are a cost you take on the day two consumers of the same machine first disagree about a driver version - not before, and not never. The failure mode to avoid is the middle state: several suites, one home, and no rule about who changes it, where the first symptom of an upgrade is a red run in a suite nobody upgraded.