Your Appium library loan-renewal suite needs an unreleased driver fix - how do you install that build?

## The short name is a catalogue lookup, not the only way in `appium driver install uiautomator2` works because the CLI carries a list of official extensions and can turn that short name into a package. Everything outside that list - a community driver, your fork of one, a branch carrying a fix that has not been published - needs you to say where the package comes from, using `--source`. The **library loan-renewal** suite in this scenario is blocked on a merged but unpublished driver fix, and `--source` is how that build reaches the machine without waiting for a release. ## The four sources - `--source=npm` names a package in the registry and can pin an exact version; this is what a short name resolves to. - `--source=github` names a repository as `<org>/<repo>`. - `--source=git` names any git URL, including a private one the host can reach. - `--source=local` names a directory on this machine - a checkout you are editing, or a build your own tooling produced. For `github` and `git` the repository alone is not enough: Appium also wants `--package` naming the package inside it, because a repository may hold several and the manifest has to record one name. For `local`, the directory must already be a complete, built extension package - Appium installs it, it does not build it for you. ## What gets recorded Whichever source you use, the outcome has the same shape: the extension lands under `APPIUM_HOME`, and `extensions.yaml` gains an entry naming the extension, its package, its version and where it came from. `appium driver list --installed` then prints that entry. This matters more here than in the ordinary case, because six weeks later the difference between a driver from the registry and a driver from somebody's branch is invisible in behaviour and obvious in the manifest. ## What a git or local install costs you | | published install | git or github install | local install | |---|---|---|---| | What you get | an immutable published version | whatever the branch points at now | whatever is on this disk now | | Reproducible elsewhere | yes, by version | only if you pin a commit or tag | no | | Update path | `appium driver update` | reinstall from the source | reinstall from the directory | - A branch install is a moving target: the same command on two machines a week apart can produce two different drivers. - Nothing about the source changes the driver's own requirements - it still declares a peer dependency on the server's major line, and an unpublished build may expect a newer server than you run. - A local install ties the machine to a path; move or delete that directory and the next reinstall fails for reasons that have nothing to do with Appium. - The **Android** UiAutomator2 driver and the **Apple-platform** XCUITest driver are separate packages in separate repositories, so forking one leaves the other on its published version. Say that out loud in a suite that runs both, or someone will assume the whole toolchain moved. ## Getting back to boring A driver installed from a branch is a **temporary** state and deserves to be labelled as one: 1. Pin what you can - a tag or commit for a git source, an exact version for a registry source - so the install is repeatable while it lasts. 2. Publish an internal package if the fork will outlive a few days. That turns a branch install back into a pinned registry install and restores the normal update path. 3. Get the fix upstream, then reinstall the published driver and delete the special case. 4. Record the install commands where the next person will read them, because `APPIUM_HOME` is ambient state on the machine and nothing inside the suite reveals which driver build it ran against. ## Why interviewers ask this one The flag itself is a lookup. What the question tests is whether you can hold two things at once: that Appium's extension model deliberately makes an unpublished driver installable, and that installing one puts a machine into a state no version number describes. The strong answer names `--source` and `--package` in one breath and, in the next, says how the fleet gets back to a published version and who is responsible for making that happen. The weak answer either waits for a release it cannot influence, or installs the branch and never revisits it - which is the same failure a year later, wearing a different name.