The required dependency list is empty, and the extras carry two of everything

The manifest declares seven point zero, the newest release is six

Two version numbers matter in this repository and they do not agree.

The build manifest declares the version as a bare major. It is not 6.5.4 with a patch number, and it is not a pre-release marker either: it is simply the next major, on the branch that is working towards it.

The release tags tell the other half. The three most recent are 6.5.4 in late September 2026, 6.5.3 in August and 6.5.2 in July, so the shipped line is the six series and it moves every three to six weeks. The branch was pushed to on the same day this description was written, so the code is moving faster than the tags.

The practical consequence is that the two halves of the project are on different version numbers by design, and a build from the branch reports a whole major rather than anything you can compare against a release. If you are pinning this in a package file, pin the tag you tested, not the branch, and read the changelog between the two.

The required dependency list is empty and everything is an extra

The dependency section of the manifest is an empty list. There are no required runtime dependencies at all.

Everything lives in two optional groups. The graphics group is two OpenGL bindings, one of them an accelerator companion. The command line group is where the project actually lives, and the most striking thing about it is how often the same capability appears twice.

There are two SSH client libraries. There are two TLS stacks. There are two proxy libraries, which appear to be a rename of one another rather than two independent implementations. And there are three separate network discovery stacks: an interface enumerator, a DNS resolver, and a zero-configuration service discovery library.

Then two more of the same families appear commented out: a message bus library and a Linux-native discovery daemon. Reading the pattern together, the project has accumulated parallel implementations of the same job, one of which is currently disabled, and none of the comments say which is preferred. If you are packaging this, that is the list you will have to make sense of.

A compiler toolchain is a build requirement, and the file admits it litters the tree

The build requirements are two, and the second one is a compiler front end. Cython is needed to build the package, which means a source install needs a working toolchain and the headers to match whatever the extensions bind to.

The build script carries a comment admitting the consequence, in the form of a to-do marker: the Cython extension build leaves crud in the source directory. That is a known and unfixed hygiene problem, documented in the file that causes it.

There is also a Python version gate in the same script. It checks the running interpreter against 3.10 and refuses anything older with an explicit message saying support for older versions has been dropped. So an unsupported interpreter produces a clear error rather than a syntax failure later, which is the kind of check that saves an afternoon.

git clone https://github.com/Xpra-org/xpra; cd xpra
python3 ./setup.py install

The platform detection in that script is broader than you would expect from the download page: Windows, macOS, Linux, NetBSD, OpenBSD and FreeBSD each get a flag, plus a POSIX test and a word-size calculation done by asking the interpreter how big a pointer is.

The first import in the build script cannot succeed on any supported Python

Here is a small piece of dead code that has outlived the library it imports.

The build script tries to import its setup function from the standard library's distutils module first. If that raises, it prints a message saying there is no distutils and that it will try setuptools instead, then retries the same imports from setuptools. If that fails too, it prints an instruction to install setuptools and exits.

Distutils was removed from the standard library in Python 3.12. The project requires 3.10 or newer and classifies itself for 3.10 through 3.12, so on the versions it officially supports, the first branch either succeeds on 3.10 and 3.11 or fails on 3.12 and later. On a modern interpreter the failure path is the normal path, and every build begins by printing a message about a missing module that was removed on purpose.

The rest of the header explains the script's structure better than any documentation would. It inserts its own directory into the import path with a comment saying it is required for the modern build standard, then imports the package it is about to install and asserts that the import succeeded. The build script depends on the package importing cleanly, which is why the version check and the compile step are in the same file.

Three modes, one TCP port, and a QUIC library in the dependency list

The feature this project is named for is the seamless mode: run a program on a remote host, point its display at the local machine, then disconnect and reconnect from the same machine or another one without losing state. The example is one command that starts a terminal emulator over an SSH URL and displays it locally, with a reminder that the program has to exist on the host.

xpra seamless ssh://USER@HOST/ --start=xterm

Two other modes sit alongside it. One attaches to a desktop session that is already running on the remote machine, so you see the whole desktop rather than individual windows. The other starts remote desktop sessions. On top of those sits a proxy server that can act as a relay or a front end for several server sessions at once.

The transport story is where the dependency list pays off. A single TCP port carries encrypted TLS, SSH, secure web sockets, the RFB protocol and more, and the command line group includes a QUIC implementation and an event loop library, so the many-protocols claim in the README is backed by real code rather than marketing. Audio in and out, printers, the clipboard, system trays, notifications and webcams are all forwarded too, along with file and URL opening, high bit depth content and the display's pixel density.

Multicast discovery makes a client find the server, and also announces it

There is a feature in the network section that deserves to be read as a security decision rather than a convenience.

Sessions can be announced automatically on local networks using multicast service discovery, so that clients connect more easily using a graphical browser that finds them for you. There is even a command for that browser.

Read plainly: a running server tells every other machine on the segment that it exists, and ships a tool whose job is to find those announcements. That is exactly what you want on a network you control and exactly what you do not want on a shared one, a conference network, or anywhere the segment includes machines you do not administer.

The project does document the protections available. Connections can be secured with encryption and with a choice of authentication modules, and the official downloads are signed. What is not documented here is a default, so the sensible reading is that you have to choose your discovery and authentication story yourself rather than inheriting one.

Three authors, one maintainer, and funding aimed at one person

The manifest names three authors and one maintainer, and the same person appears in both lists. Two of the authors have addresses at the project domain and one uses a personal mail host, which is what a fifteen-year project with rotating hands looks like.

Funding is a single link, and it points at a personal sponsorship page rather than the organisation. So a project with an organisational name, an organisation account, a discussion area and a code of conduct routes its money to one individual's profile.

That is not a criticism; sponsorship pages are how most maintainers take money, and keeping it personal is often the point. It does tell you where the bus factor sits, and it is the same person who holds the maintainer role in the metadata.

The rest of the repository is organised like a project that has been running for a long time and expects to keep running. There is a blame-ignore file so that mass reformatting does not destroy the history, a pre-commit configuration, a static analysis configuration, a licence file using the traditional name, a manifest file for packaging, a Debian directory, a packaging directory, a docs directory and a tests directory.

Editorial conclusion

Xpra is the right tool when you want individual remote applications rather than a remote desktop, or when a desktop session must outlive your connection, and the fact that it is a fifteen-year-old GPL project with a release every few weeks is not a warning sign on its own. Three things to check before you put it on a network. Decide how sessions are discovered, because automatic announcement over multicast DNS makes a client able to find your server and also tells everyone else on the segment that it exists. Decide how the connection is authenticated and encrypted rather than accepting the first transport that connects. And if you build from source, read the setup script first, because it needs a compiler toolchain, it refuses old interpreters outright, and it admits in a comment that it leaves build artefacts in your source tree.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. Xpra-org/xpra on GitHub