The crate is bob-nvim, the binary is bob, and the download is bob

Three names for one tool, and you need all three

The naming is inconsistent in a way that will cost you a search if you do not know it. The published tags run 4.1.7 in April 2026 and 4.2.0 in September 2026, and the repository is bob while the executable you type is bob. The Cargo package, and therefore the crates.io name, is bob-nvim, which is why installing from crates.io means cargo install bob-nvim while the command you then run is bob. The downloadable artifacts are named separately again, following a pattern like bob-{platform}-x86_64.zip, with AppImage builds for Linux named bob-linux-x86_64-appimage.zip and bob-linux-arm-appimage.zip. Cargo.toml confirms the split: the package block declares name = "bob-nvim" at version 4.2.0 with edition 2024 and rust-version 1.85, while the bin block declares name = "bob" pointing at src/main.rs. It also declares a profile called optimized, inheriting the standard shipped profile with opt-level = "z", which is a size-over-speed choice for a binary people download and run many times a day.

Five install paths, and one instruction at the end of each

Installation is documented five times over, which is generous and also a sign of how many kinds of user there are. The recommended path is a bundled script:

# on Unix
curl -fsSL https://raw.githubusercontent.com/MordechaiHadad/bob/master/scripts/install.sh | bash

with a PowerShell equivalent for Windows. Each script downloads the newest published build for your platform and links the bob binary into a user-local bin directory, and if the installer warns about your PATH you add the directory it prints. The manual path is the same: download bob-{platform}-x86_64.zip, unzip it, run it with bob. Nightly is the same flow but from the tag named nightly. Arch users have a package in the extra repository with pacman -S bob. From source it is cargo install --git https://github.com/MordechaiHadad/bob.git, and from crates.io it is cargo install bob-nvim. Building from source needs rustup installed, and the prerequisites for building Neovim itself are CMake and Git everywhere, Visual Studio Build Tools with the C++ extension pack on Windows, and Clang or GCC on Unix.

Five verbs, and only one of them launches the editor

The command surface is small enough to hold in your head. A version string is either vx.x.x or x.x.x, with v0.6.1 and 0.6.0 given as examples, and the same target vocabulary applies to several subcommands: nightly, stable, latest, a specific version string, or a commit hash. bob use switches to a version and by default auto-invokes the install command when that version is not already present, with --no-install stopping that behavior. bob run launches a specific installed version with arguments passed straight through to Neovim, so bob run nightly --clean my_file.txt is a complete example. bob install installs a version and doubles as the way to refresh an out-of-date nightly. bob sync reads a version out of a file when Config::version_sync_file_location is set, which is how a project can pin the editor version for everyone on the team. bob uninstall removes a version, and with no argument it prompts to select several.

The proxy executable is why old installations break

Three of the dated notices trace back to a single design decision: bob runs Neovim through a proxy executable rather than pointing at a binary directly. The 2023-02-13 notice describes the switch and the manual migration, which is to remove the Neovim path from the global PATH, delete the neovim directory under ~/.local/share on Unix or AppData\Local on Windows, and note that the downloads directory property in the configuration file was renamed. The 2024-03-04 notice covers macOS, where a change in Neovim's own binaries led to arm support but with breaking changes for the proxy: remove the nvim binary from nvim-bin, drop your downloaded bob binary into that same directory, and rename it to nvim. That is a manual three-step repair, and the notice says it will not be necessary soon. A fourth notice, 2024-05-19, affects people who built Neovim from a source commit: those builds now need a full-hash.txt file at the root of the directory containing the commit hash, or a rebuild.

Nightly is a scheduled build, not a promise

Nightly builds are produced every 72 hours from the dev branch and are labelled pre-release artifacts, with the README saying they may contain bugs or unstable features and telling you to use them at your own risk. That cadence is the useful detail: three days is short enough that a nightly build tracks the branch closely, and long enough that two people installing on the same afternoon get roughly the same thing. The install path is identical to a normal build except that you pick the tag named nightly, download the same bob-{platform}-x86_64.zip naming, unzip and run. The pairing with bob install is worth noting, since the command doubles as the way to update an outdated nightly in place, which means you are not downloading a new bob each time, only a new editor.

Dated notices from 2022 to 2026 tell you what changed

The README opens with a notices list rather than a summary, and reading it in order tells you what has changed about the project's assumptions. In 2022-10-29 the symbolic link and downloads folder moved on macOS from /Users/user/Library/Application Support to ~/.local/share, with instructions to move your downloads and update your PATH. In 2024-05-17 support for nvim-qt was deprecated because newer Neovim builds no longer support it, with a recommendation to move to a different GUI or the terminal. In 2025-12-30 OpenSSL builds were fully deprecated due to redundancy and maintenance overhead, and the standard builds were recommended instead. The most recent entry, 2026-07-01, covers sudo behavior: bob is now mostly XDG compliant when running under sudo, respecting XDG_DATA_HOME and XDG_CONFIG_HOME before falling back to the real user's home directory, with sudo -E needed to preserve those variables. The same entry notes that the users and nix crate dependencies were replaced with direct libc calls for sudo user detection.

Where bob is the wrong tool

Four cases. The first is a machine that already manages Neovim through a package manager. The requirements section says to make sure you do not have Neovim installed by other means, and the reason is structural rather than cosmetic: bob installs its own binaries, links them, and proxies the executable, so two installers fighting over the same nvim on your PATH is a configuration that breaks in ways that are hard to trace. Pick one owner. The second is someone who wants a single pinned editor. If your team agrees on one version and never tests against another, a version manager is machinery you do not need, and the nightly track in particular adds a moving target to your editor. The third is a build-from-source workflow. The 2024-05-19 notice means source builds of Neovim need a full-hash.txt file or a rebuild, so if you maintain your own editor builds, bob now carries a requirement it did not have. The fourth is expectations about the crates.io package. cargo install bob-nvim installs something packaged by the community rather than the same artifact you get from the downloads page, so if you pin versions for reproducibility, know which channel you are pinning and that the two do not move together.

Editorial conclusion

Bob suits someone who works across several Neovim versions, including nightly, and wants one command to install and switch between them without going through a package manager on every change. It does not suit a machine where Neovim already comes from one, since the README asks you to remove that first. Before adopting, install with the bundled script or with pacman on Arch, confirm bob resolves on your PATH, and read the dated notices if you are upgrading an existing bob rather than installing fresh.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MordechaiHadad/bob on GitHub
4. README
5. Releases