# tuistore: a TUI app store that picks the right install command for your machine > tuistore is a Python and Textual terminal application that catalogs hundreds of command line tools, ranks install methods against the package managers actually present on your system, and runs the chosen command with streamed output. The catalog is broad and the install engine is the interesting part, but the quality of each entry depends on where its command came from. **Gheat1/tuistore** — 🛍️ The TUI app store: browse, search & one-key-install hundreds of terminal apps. - Repository: https://github.com/Gheat1/tuistore - Stars: 429 · Forks: 17 - Language: Python - License: NOASSERTION - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/gheat1-tuistore ## The two problems tuistore is built around Terminal tool discovery and terminal tool installation are separate chores, and tuistore treats them as one. The README frames the first as trawling GitHub and awesome-lists, and the second as guessing whether a given project wants cargo install, brew install, pacman -S, uv tool install, a curl piped to sh, or a source build. The second half of that complaint is the sharper one: the README notes that half the commands in a project's own instructions are for the wrong OS. The audience is developers who live in a terminal and already have several package managers installed. tuistore does not ship its own package format or its own registry. It is a catalog plus a decision layer over the toolchains you already run, and the README is explicit that tuistore itself installs nothing but itself. If you have exactly one package manager and never install anything outside it, the decision layer has little to decide. ## How the install engine chooses a command The mechanism has five visible stages. First, tuistore inspects the machine: operating system, Linux distribution family, CPU architecture, and which package managers and toolchains are present on PATH. Second, each catalog entry carries install methods that are gated on platform, so pacman -S is only offered on Arch and cargo only where cargo exists. Third, those methods come from three sources that the interface labels separately: official commands the project itself documents and that tuistore's maintainers hand-verified for the featured suite, commands scraped out of each repository's README, and unverified best guesses derived from the repository's language. The fourth stage is ranking. Runnable methods are ordered with a managed install such as brew, cargo or uv ahead of a remote curl piped to sh, and verified entries ahead of guessed ones. The winner becomes the default and every alternative stays one keypress away. The fifth stage is disclosure: the install screen shows the exact command with a verified or unverified badge, warns on remote scripts, and the r key opens the project's README inside the store. The README states that the command runs in your login shell with live streamed output and that nothing runs silently. That disclosure is the strongest design decision here. Package managers that guess at installation usually hide the guess behind a progress bar. tuistore puts the guess on screen and gives you a key to reject it. ## Installing tuistore and installing your first tool The README offers a one-liner that selects among uv, pipx and pip, and installs uv first if none of the three is present: ```bash curl -fsSL https://raw.githubusercontent.com/Gheat1/tuistore/main/install.sh | sh ``` Homebrew users can take the tap route instead: ```bash brew install gheat1/tuistore/tuistore ``` PyPI is the third path, and the README marks the uv variant as the recommended one: ```bash uv tool install tuistore pipx install tuistore pip install tuistore ``` Arch users can install from the AUR with yay or another helper: ```bash yay -S tuistore ``` On Windows the README says to work in PowerShell or Windows Terminal, install whichever package managers you already use, and run the same one-liner; winget, Scoop, Chocolatey, uv, Cargo, Go and npm are detected automatically, and Windows-only methods appear only on Windows. Once installed, the entry point is a single command, and the project metadata confirms the console script name: ```bash tuistore ``` The README describes the interaction as type to search, arrow to browse, i to install. Pressing slash focuses the search field, where you can match on a name, a description or a language. Enter opens or focuses a tool, i installs it, a picks a different install method, and r reads the project's README in-app. Before you confirm an install, the screen should show the exact command with its verified or unverified badge; that badge is what you are checking. ## The catalog is not a dependency manager The most important limitation follows from the design. tuistore drives the package managers you have, so what you end up with is whatever those managers produce. There is no lockfile in the repository layout, no pinned version per tool, and no record of a resolved dependency graph. Reproducing one developer's tool set on another machine means reproducing their package manager state, not replaying a manifest. The second limitation is the provenance split. Only the featured suite is described as hand-verified. Everything else is either scraped from a README or inferred from the repository's language, and the README itself flags the inferred class as a best guess. A scraped command is also a snapshot: if an upstream project changes its recommended install path, the catalog entry does not follow automatically unless the catalog is refetched. The manage menu includes refetching the catalog, which is the mechanism for that, but it is a manual action. A third constraint is scope. tuistore is a store for terminal applications, not for libraries. If what you need is a Python package to import, or a system library for compilation, this is the wrong layer and you should stay with pip, your distro, or a build system. ## tuistore versus a plain package manager The honest comparison is not against another TUI store, because the README does not present one. It is against the workflow you already have: a distro package manager for system tools, a language package manager for tools written in that language, and a browser tab for everything else. A distro package manager such as pacman or apt resolves dependencies, tracks versions, and can roll back a transaction. tuistore does none of that. It selects a command and hands it to the manager that owns it. The difference in approach is discovery and portability: pacman knows nothing about a Rust binary that is best installed with cargo, and cargo knows nothing about a Go tool. tuistore's catalog spans those ecosystems and picks per tool, which is exactly the gap the README describes. The cost is that you now have a second place where installation decisions live, and it is a catalog rather than a transaction log. If you want one manager to own everything and you are willing to accept its package selection, stay where you are. If your tool set is genuinely polyglot, the per-tool routing is the feature you are paying for. ## Updating, uninstalling and what tuistore remembers tuistore keeps a record of what it installed, including which manager and which command, and it also detects tools you already had. Detection is not limited to binaries on PATH: the README says it queries brew, uv, npm, cargo and pipx for their installed lists, which is how names that differ from their binaries still show up, with ripgrep mapping to rg, bottom to btm and git-delta to delta. The Installed filter lists the result. On an installed tool, u updates and x uninstalls using the command appropriate to the manager, such as brew upgrade, uv tool upgrade or cargo uninstall, with output streamed. For a tool tuistore did not install, the README says it asks which manager you used, which is a reasonable fallback and also an admission that detection cannot always attribute a binary to a source. The manage menu behind the comma key includes updating tuistore itself, refetching the catalog, and an update-everything action that chains upgrades across managers. Recent release notes state that self-update matches the install source, so updating tuistore should follow the route you installed it by rather than assuming one. ## Licence, maintenance and the cost of keeping up The package metadata declares GPL-3.0-or-later, while the repository's licence field is reported as NOASSERTION, so the pyproject declaration is the clearer signal of intent. GPL-3.0-or-later is a copyleft licence. If you are only running tuistore as a tool, that is a normal end-user situation, but if you intend to embed it in a product or ship a modified binary, the copyleft terms apply to distribution and you should read the LICENSE file rather than rely on a summary. Nothing here is legal advice. On maintenance, the last push to the default branch was on 2026-08-18, which is recent, and the repository is not archived. The release history shows v0.4.5, v0.4.3 and v0.4.2 within a two-day window in July 2026, with v0.4.5 adding 800+ tools and support for Gentoo, Solus, Void and Alpine. That cadence suggests active work, but the practical upgrade cost is not in the Python package. It is in the catalog. Every new distribution family, package manager or upstream install change is a catalog edit, so the project's maintenance burden scales with the number of tools it lists rather than with the size of its own codebase. ## Conclusion tuistore suits developers who already mix brew, cargo, uv, npm and distro packages and are tired of translating install snippets from the wrong operating system. It is the wrong tool if you want a reproducible, pinned dependency graph, since it drives your existing package managers rather than replacing them. Before adopting it, install it with uv or pipx, run tuistore, and inspect the badge on the install screen for the tools you care about; the README states that official methods are hand-verified while scraped and guessed ones are not. ## FAQ ### What does TUI software mean? A TUI is a text user interface, an application that runs inside a terminal and is driven by keyboard and sometimes mouse input rather than by windows and widgets. tuistore is itself a TUI, and its catalog is made up of terminal applications of the same kind. ### What are TUI interfaces? They are the screens and controls a terminal application presents, built from text cells instead of graphical elements. In tuistore the README describes a search field, a browsable list, an install screen showing the exact command, and an in-app README viewer, all navigated with keys such as i, a, r and the slash key to focus search. ### What is a TUI vs GUI? A GUI draws windows, buttons and images and is usually driven by a pointer, while a TUI draws in the terminal and is driven mainly by the keyboard. tuistore is a TUI, though the README notes that rows, the hint bar and the pane dividers also respond to clicks. ### What are the best TUI applications? tuistore does not rank tools by quality, but its catalog is seeded from the awesome-tuis list and covers both full-screen TUIs and command line tools such as fastfetch, neovim, ripgrep, bat, eza, starship, zoxide and fzf. The Installed filter shows which of them you already have. ## Sources - [Gheat1/tuistore on GitHub](https://github.com/Gheat1/tuistore) - [Issues](https://github.com/Gheat1/tuistore/issues) - [README](https://github.com/Gheat1/tuistore/blob/main/README.md) - [Releases](https://github.com/Gheat1/tuistore/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gheat1-tuistore