Rare: a PySide6 desktop front end for the Legendary game launcher

A window over a command line tool

Epic Games Launcher is closed source, and the usual answer on Linux is Legendary, a command line tool that talks to the Epic Games services. The problem with a command line tool is that it is a command line tool. Rare is the fix: a graphical interface for Legendary, written in PySide6, presented as an open source alternative to Epic Games Launcher.

That is the whole product, and being clear about it is the right starting point. Rare is not a reimplementation of the store, not a DRM bypass, and not a game manager with its own library database. It is a front end over an existing tool, and the README says as much in one line: a graphical interface for Legendary, a command line alternative to Epic Games launcher, written in PySide6.

The reasons the project gives are worth reading for what they reveal about the priorities. Rare runs natively and supports most of the major platforms. It gets out of your way when you do not need it, so you can enjoy your games. It tries to be as lightweight as possible while still offering a feature-full experience. It integrates with Legendary, and the README attributes that to both projects being written in Python. The last reason on the list is packages, packages everywhere, which is a joke about distribution but also an accurate description of the installation matrix.

The screenshots show the scope: a library with game covers, a vertical list view, a game details page, per game settings, a downloads screen and an application settings page. That is a conventional launcher interface, and the point of building it in Python rather than as a web app is native behaviour and a light process.

The dependencies pin two forks by commit hash

The pyproject file is where a project like this explains itself, and Rare's dependency list is unusual in a way that deserves attention. The runtime dependencies are requests with a ceiling below 3.0, PySide6-Essentials at 6.8.1 or newer, QtAwesome, orjson, and pywin32 on Windows only. Those are all ordinary. The interesting entries are the two git URLs:

dependencies = [
    "requests < 3.0",
    "PySide6-Essentials >= 6.8.1",
    "QtAwesome",
    "legendary-gl @ git+https://github.com/RareDevs/legendary@828850273f47432c086d758cd3391047d6dd8ddf",
    "orjson",
]

The first is legendary-gl, the Python library behind Legendary, taken from a fork hosted by RareDevs, the same organisation that hosts Rare, pinned to an exact commit hash. The second is vdf, the Valve Data Format parser, taken from a solsticegamestudios fork and pinned to its own commit.

The practical consequences are immediate. An install from source needs git and network access to GitHub, and it clones rather than downloading a wheel, so an air gapped or restricted network is a problem. A build is not reproducible from a tag alone unless that tag and those two commit hashes agree, since the upstream Legendary project can move independently of the fork.

The reason to pin rather than float is straightforward, and it is the same reason the setup file derives the version from the git tag. Rare is an application that is packaged and released, so the exact Legendary behaviour it was tested against has to be fixed.

The version itself is dynamic in pyproject, and setup.py derives it from setuptools_scm with a scheme of tag plus distance, so a build from a tagged commit reports the tag and a build from a later commit reports how far it has moved.

Five package managers, and the one-liners they give you

The installation section of the README is the longest part of the documentation, which is itself a fact about the project. It covers Windows, Linux and macOS, and it offers the same application through several channels because each platform has a different convention.

On Windows there is an .msi installer and a semi-portable .zip archive on the releases page, and the README notes that recent versions of Windows want the MSVC 2015 runtime installed. The same application is in the winget and Chocolatey repositories, with one line commands:

winget install rare

choco install rare

On Linux the primary route is a Flatpak, published on Flathub under the identifier io.github.dummerle.rare:

flatpak install flathub io.github.dummerle.rare

flatpak run io.github.dummerle.rare

There is also an AppImage on the releases page, two Arch packages, rare for stable releases and rare-git for the latest development version, and a Nix package that runs in a shell:

nix-shell -p rare

The macOS route is a .dmg from the releases page, and the README is blunt about its condition: the macOS binaries are currently not signed, so Gatekeeper blocks the application and the user has to enable it manually in Settings, Security and Privacy.

A development channel exists alongside the releases. The actions tab of the repository carries packages built from the latest commits, with the warning that they might be unstable and likely broken. That is an unusually honest note to publish, and it tells you the tagged builds are the ones to trust.

The macOS quarantine workaround and the pip escape route

The macOS instructions are the sharpest edge in the installation story, and they are worth quoting closely because they are the first thing a new user hits.

After installing the .dmg, macOS may complain that the application is damaged. The fix the README gives is a command in a terminal:

sudo xattr -dr com.apple.quarantine /Applications/Rare.app

That removes the quarantine extended attribute that Gatekeeper applied to the downloaded file, which is what allows the application to run. It is a manual step with sudo attached, and it is the price of an unsigned build. Anyone distributing Rare to their own users inherits this friction, and anyone with a managed Mac may not be able to run a sudo command at all.

The alternative the README offers is to install with pip or pipx, or from source, and that path avoids the signing problem entirely because there is no downloaded bundle to quarantine:

pip install Rare

or, for the current user only:

pip install Rare --user

The launch command then depends on the platform. On Linux, macOS and FreeBSD you execute rare in a terminal, while on Windows you execute pythonw -m rare in cmd, where the w keeps a console window from appearing.

The pip route has its own catch, which the README documents in a table of paths that may need to be in your environment's PATH. On Windows it is the Scripts folder of your Python installation, on Linux it is the .local/bin directory under the user home, and on macOS it is the bin directory under the user's Library/Python path. If the command is not found, that table is the first thing to check, and the application can also be launched from the settings screen, which creates a desktop link or a start menu link, the same effect as the --desktop-shortcut and --startmenu-shortcut command line options.

Running from source means regenerating the interface files

The advanced path in the README is a seven step procedure, and step four is the one that surprises people. This is a PySide6 application, and the interface is not written in Python alone, so the generated files have to be produced before the package will work.

Clone and enter the directory:

git clone https://github.com/RareDevs/Rare

cd Rare

Then, optionally, isolate the install in a virtual environment:

python -m venv venv

source ./venv/bin/activate

on Linux and macOS, or the activate.ps1 script under the scripts directory on Windows.

Step four is the generation step, marked optional but effectively required for a working build. You need ruff and PySide6-Essentials installed, and then three scripts run:

./tools/ui2py.sh --force
./tools/qrc2py.sh --force
./tools/ts2qm.py

The first compiles the user interface definition into Python, the second compiles the Qt resource file, and the third converts translation files. The tools directory sits at the repository root alongside a Makefile, freeze.py, a pylintrc and a packaging directory, so the generation is scripted and repeatable rather than something a maintainer does by hand.

Installation then follows the normal path, pip install . for the application and its runtime dependencies, or the extras variants pip install .[discordrpc] and pip install .[webview] for Discord Presence and Webview support. The application is then started with rare or python3 -m rare.

A Makefile, a build directory and a version read from git

The Makefile is the clearest statement of the build pipeline, and it is worth reading because it names each stage. The targets are declared as all, venv, install-deps, build-ui, build-wheel, install-wheel, clean and help, and the default target runs install-wheel, which chains the whole sequence: create a virtual environment in build_venv, install the requirements from packaging/requirements.in, build the user interface, build the wheel and install it.

The build-ui stage is the same three generation steps the README lists, expressed in the Makefile as:

$(BUILD_DIR)/.rare-build-ui: install-deps
    . $(VENV_DIR)/bin/activate && bash tools/ui2py.sh --force
    . $(VENV_DIR)/bin/activate && bash tools/qrc2py.sh --force
    . $(VENV_DIR)/bin/activate && python3 tools/ts2qm.py

The staging file pattern is a small but effective trick. Each stage is a target that depends on a marker file in the build directory, so make rebuilds only the step whose inputs changed. The install-deps stage, for example, creates the marker by installing requirements and then running touch, and the UI stage depends on that marker, so an unchanged environment does not trigger a full regeneration.

Version handling is the other notable detail. The Makefile computes the version from the git tag with a shell pipeline over git describe, and setup.py uses setuptools_scm with a custom scheme that produces the tag followed by the distance. The pyproject file lists the version as dynamic, which is what allows the packaging step to read it from the repository rather than from a hard coded string.

Packaging itself follows PEP 517, and the packaging dependency group in pyproject lists cx-freeze and nuitka as the two freezers, which is how a PySide6 application gets turned into the .msi, .zip and .dmg artefacts on the releases page. The Arch instructions in the README name the equivalent system packages, including python-pyside6, python-qtawesome, python-requests and python-orjson, along with legendary and python-vdf from the AUR.

Discord Presence and Webview arrive as optional extras

Two features are packaged as optional dependency groups rather than being on by default, and the packaging decision tells you what they cost.

The webview group installs pywebview with the gtk extra on Linux and FreeBSD, pythonnet on Windows, and pywebview with pyobjc on macOS. That is a substantial set of platform bindings, which explains why it is optional: a Webview based feature inside a Qt application means a second rendering stack and a second set of platform dependencies, and a user who never opens that panel should not pay for it.

The discordrpc group is much smaller, a single package, pypresence, which provides the Discord Rich Presence integration.

The dev group then adds the tools a contributor needs, including PySide6 stubs, qstylizer, ruff and ty, and it includes the webview, discordrpc and packaging groups so a development environment has everything. The presence of a type checker named ty in the dev group and a pylintrc at the repository root suggests the project checks its own typing rather than shipping untyped code.

The licensing detail is worth stating plainly as well. The licence field says GPL-3.0, and the pyproject file spells it as GPL-3.0-or-later with the licence text in the LICENSE file, plus a separate LICENSE.rtf at the repository root. That copyleft matters for anyone who reads the source to build a modified launcher, and it is the opposite of what a proprietary project embedding Rare would want. That is a licensing observation rather than legal advice.

There is also a file named .noai at the root of the repository. The README does not describe what it contains, so it is worth reading before you rely on this project as a source of training or generated data.

Legendary in a terminal instead of Rare in a window

The alternative worth taking seriously is not another launcher, it is the tool underneath. Legendary is a command line alternative to the Epic Games launcher, and everything Rare does, it does without a GUI.

The difference in approach is direct. Legendary gives you a command and its output. Rare gives you a library browser, a details page, a downloads view and settings screens, and it tries to stay out of the way when you are playing. If your use is downloading a handful of games once, the command line tool is faster and there is nothing to install beyond Python. If your use is browsing a large library, checking what a game contains, or keeping a queue of downloads going, the interface is the reason Rare exists.

The second alternative is the distribution channel rather than the application. A Flatpak or an AppImage gives a sandboxed, self contained install with no Python on the system, while the pip route uses the Python you already have and gives you a package you can pin. The trade is isolation against upgrade control, and the README covers both ends, with the pip route documented down to the PATH table and the Flatpak route down to the two one-line commands.

The third is the official launcher, which Rare describes itself as an alternative to. That comparison is about licensing and platform support rather than features, and the README does not attempt a feature by feature comparison, so the honest statement is that Rare is the open source option for people who want the Epic library without the official client.

For a scripted environment, the answer is clear. For a desktop, Rare is the only one of the three that shows you a library.

Editorial conclusion

Rare suits a Linux, macOS or Windows user who wants the Epic Games library and downloads in a desktop window without the official launcher, and it is a poor fit for a scripted or headless setup, where Legendary on the command line does the same work with less machinery. Before installing, check the two things that make or break a Rare deployment: the pyproject dependencies point at git commits of a RareDevs fork of legendary-gl and a solsticegamestudios fork of vdf, so an install needs git and access to GitHub, and the macOS build is unsigned, so the first launch needs the quarantine attribute removed by hand. If you want a stable build rather than the latest commits, use the release page packages, since the recent tagged versions are all marked as pre-releases.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. RareDevs/Rare on GitHub
4. README
5. Releases