Personal OS Setup: A Python TUI That Configures Windows, Linux, macOS, WSL2, Google TV and Home Assistant

The problem: setup knowledge scattered across four operating systems

Most developers keep their machine setup in their head or in a half-finished notes file. The commands for installing Zsh and Oh-My-Zsh on macOS are not the ones for Ubuntu, the WSL2 configuration steps are different again, and the Windows side has its own conventions around Windows Terminal and PATH. Personal OS Setup packages that knowledge as a Python TUI app plus a documentation hub. The README describes it as "An opinionated terminal UI app + documentation hub for a fast, consistent setup across Windows, Linux, macOS, WSL2, your living room (Google TV + Stremio), and your home server (Home Assistant)." The intended user is one person setting up their own machines, not a platform team. That framing matters, because the design choices that follow (interactive menus, auto-update on launch, a single installed checkout) all assume a human at a keyboard who trusts the source.

What the TUI actually does, and what the documentation hub covers

The repository splits into two deliverables. The first is the app: a cross-OS Python TUI for "installing packages and running system actions", with the README naming Zsh/Oh-My-Zsh, WSL management, GPU drivers, dotfiles sync via chezmoi, Windows Terminal config, and Docker post-install as examples. The second is the docs, covering the same desktop platforms plus TV setup (Google TV with Stremio) and a home server (Home Assistant). The README points to the project website for the full feature list and supported package managers rather than enumerating them inline, so the exact package set is something you have to check on the site or in the TUI menu itself. That is a real gap in the repository text: you cannot tell from the README alone whether your particular toolchain is covered. The topics list (cuda, wsl, windows-11, ubuntu, macos, shell) suggests GPU and development tooling are in scope, and the description explicitly mentions WSL2, GPU drivers and development tools.

Installation: one command per platform, then a single binary name

On Linux, WSL2 and macOS the documented entry point is a shell one-liner that pipes a remote script into sh: sh -c "$(wget https://raw.githubusercontent.com/AmineDjeghri/personal-os-setup/main/install_unix.sh -O -)". The script installs the repository into ~/.personal-os-setup, or reuses and updates an existing copy there, and links a personal-os-setup command into ~/.local/bin. If you run it from inside an existing clone it updates that checkout in place rather than creating the hidden directory. On Windows 11 the equivalent is a PowerShell command that downloads install_windows.ps1 to a temp path and runs it with -ExecutionPolicy Bypass, and it must be run as administrator. That script installs into %USERPROFILE%\.personal-os-setup and adds personal-os-setup to PATH. After either path, you start the app by typing personal-os-setup. For contributors there is a second route: git clone the repository, then ./install_unix.sh or ./install_windows.ps1, or make install-dev && make run. The README also documents make vm-cachyos, make vm-ubuntu-server and make vm-ubuntu, which spin up disposable KVM/QEMU/libvirt VMs so the setup can be tried before it touches a real machine. That VM target is the most useful safety feature described in the material, and it is the one I would use first.

Auto-update on launch is the design decision to think hardest about

The README states that the app "auto-updates on every launch": it runs a git pull on the installed checkout before starting the UI. This is convenient and it is also the sharpest trade-off in the project. Every time you type personal-os-setup you are executing whatever the tracked branch contains at that moment, on a checkout that the same branch controls. There is no documented pinning mechanism, no version flag, and no release channel described in the README, even though the project publishes tagged releases (v2.14.0, v2.13.2, v2.13.1 in September 2026). If you want the v2.14.0 you reviewed to be the v2.14.0 that runs tomorrow, the material does not tell you how to get that. The flip side is that the maintainer's own update notes table (macOS 26, CachyOS kernel 7.1.8-1-cachyos, Ubuntu 24/26 server, Windows 11/WSL 2) stays current without user action. For a personal machine where you would otherwise forget to pull, that is a reasonable bargain. For anything shared, it is not.

Where it breaks down: unattended use, auditing, and forks

Three limitations follow from the material. First, the interface is a TUI. Anything that cannot answer a menu prompt, such as a CI runner, a cloud-init script, or a golden image build, is out of scope; the README offers no non-interactive mode. Second, the install path is a remote script piped into a shell or run with ExecutionPolicy Bypass as administrator. That is standard practice for personal setup tools and it is still a supply-chain decision you are making once per machine, with the repository's own contents as the only thing you can inspect beforehand. Third, the contributing section warns that forking is awkward: the README advises that a fork "stays ahead of the original repository at all times, never behind", tells you to add the original as an upstream remote with git remote add upstream and git fetch upstream, and warns that a merge "will conflict on most shared files" plus anything fork-specific that upstream also touched. That is an honest description of a project whose value is the opinionated content, not a plugin framework. If your setup diverges from the author's, you are signing up for recurring merge work, and the README's own advice is to resolve conflicts file by file and review git diff --staged before committing.

The alternative: declarative configuration management

The obvious comparison is a declarative tool such as Ansible, or chezmoi used directly rather than through this TUI. The difference in approach is not cosmetic. Ansible describes desired state in YAML playbooks and converges a host toward it, idempotently, with no prompts; you can run it against one laptop or fifty, and the playbook is the artifact you review and version. Personal OS Setup does the opposite: it presents a menu, you pick an action, and it runs it now. Chezmoi is already inside the project as the dotfiles sync mechanism, which is a useful signal. If dotfiles are your main pain, using chezmoi directly gives you templating and a diff-before-apply workflow without an intermediary TUI. If package installation across mixed OSes is your main pain, Ansible roles with per-platform conditionals give you a repeatable record. Personal OS Setup's advantage over both is discoverability: it tells you what is worth installing, which neither Ansible nor chezmoi does. Its disadvantage is that nothing it does is captured as a reviewable desired-state file.

Maintenance, licensing and what to check before you commit

The project is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained; that is a summary of the licence identifier in the repository, not legal advice, and the LICENSE file is the authoritative text. On maintenance, the release cadence visible in the material is rapid (three tags between 7 and 8 September 2026, with v2.14.0 on 8 September and the last push on 9 September 2026), which cuts both ways: fixes arrive quickly, and the auto-pull means you receive them whether or not you wanted them that morning. The repository also ships skills under .claude/skills/ for working with the codebase using an agent, which is a maintenance convenience for contributors and irrelevant to end users. Before adopting, check three concrete things: the install location and whether a hidden ~/.personal-os-setup directory fits your backup and sync setup; the upstream remote your checkout tracks, since that is what git pull will fetch on every launch; and the TUI menu contents against your actual toolchain, because the README defers the package list to the project website. If the menu covers your stack and you are the only user of the machine, the setup cost is one command. If it does not, the fork-and-merge path described in CONTRIBUTING.md is the real commitment.

Editorial conclusion

Adopt Personal OS Setup if you are a single developer or power user who wants an interactive checklist for Zsh, Oh-My-Zsh, WSL management, GPU drivers, chezmoi dotfiles sync, Windows Terminal config and Docker post-install on a machine you own, and you are comfortable with the app running git pull on every launch. Do not adopt it for fleet provisioning, CI images, or any host where a human cannot answer a TUI prompt, and do not treat it as a security-reviewed installer. Verify first that the install directory (~/.personal-os-setup on Unix, %USERPROFILE%\.personal-os-setup on Windows) is acceptable on your filesystem, that the upstream remote it pulls from is the one you intend to track, and that the TUI menu actually contains the packages you need rather than the author's preferred set.

Official sources

1. AmineDjeghri/personal-os-setup on GitHub
2. License: MIT
3. Project website
4. README
5. Releases