∘ MIT license ∘ P̶y̶P̶I ∘ D̶o̶c̶u̶m̶e̶n̶t̶a̶t̶i̶o̶n ∘ Source code ∘ Bug reports ∘ Support
Polycotylus converts Python packages into native Linux distribution packages such as RPMs or APKs. It builds on each target Linux distribution (thus dodging the usual Linux nightmare that is ABI compatibility) and uses each distribution's packaging tool. In the process, it produces a build script which, if your project is open source, can be submitted upstream so that your package will become available on official package repositories (although please don't do this yet – I want to get some form of review from the distribution maintainers first).
Polycotylus uses Docker to virtualize each Linux distribution and Qemu to virtualize almost any architecture meaning that you can build for any supported distribution or architecture from a single machine. You can even build on Windows or macOS thanks to Docker Desktop. You can also build apps for Linux phones: running polycotylus manjaro --architecture aarch64 will build an app installable on a phone running Manjaro or polycotylus alpine --architecture aarch64 will build a postmarketOS compatible app.
Unlike PyInstaller, Flatpaks or Snaps, polycotylus does not bundle dependencies into your packages – rather dependencies (including Python itself) are declared as such in the package's metadata where the end user's system package manager will see and act upon them. This makes the packages tiny, updates modular and propagation of security patches for vulnerabilities in your dependencies no longer your problem. Complex system dependencies such as GStreamer or GTK can be declared in addition to PyPI packages turning them from packaging nightmares into just another dependency. This approach also solves the standard UNIX question of should I include libXYZ in my package to which the answers yes and no are often simultaneously wrong.
Polycotylus doesn't just dump your code into an archive and hope for the best – it verifies it too! It installs your package into a clean, minimal Docker container and runs your test suite inside of it. Given even a modest test suite, it should be almost impossible to forget a dependency or miss a data file without polycotylus letting you know.
For GUI applications, using a system package manager also allows you to add desktop integration. This means registering your application so that launch menus (e.g. Gnome's App tiles) and file browsers know that your application exists, adding icons, descriptions, registering supported file types, etc.
Polycotylus is limited by a hard constraint in that it can not support any target Linux distribution that does not provide setuptools>=61.0 in its official package repositories. This unfortunately rules out all of the stable/long term support distributions (which also happen to be the most popular) currently including all stable branches of Debian, Ubuntu <23.04, SLES, OpenSUSE Leap and all of the RedHat/CentOS-like distributions par Fedora ≥37. This leaves rolling build distributions and fast releasing distributions with low latency package repositories.
| Distributions | Supported versions |
|---|---|
| Alpine | 3.17-3.19, edge |
| Arch | rolling |
| Debian | 13 (pre-release) |
| Fedora | 37-40, 41 (rawhide) |
| Manjaro | rolling |
| OpenSUSE | Tumbleweed only (rolling) |
| Ubuntu | 23.04-24.04 |
| Void | rolling |
This project is still fairly work in progress. It is not available on PyPI. To use this project as it is right now, you will have to install polycotylus from version control (instructions below). It does have documentation but that documentation is not on readthedocs – you'll need to build that from source too:
git clone git@github.com:bwoodsend/polycotylus
cd polycotylus
pip install -e .
pip install -r docs/requirements.txt
cd docs
make html
xdg-open build/html/index.htmlIn terms of feature completeness:
- The biggest gaping feature gap is polycotylus's requirement that all your dependencies are already available on each target distribution's repositories. If your application is made up of multiple custom packages or depends on an unavailable 3rd party package then polycotylus is useless to you. For this, the plan is to facilitate making personal package repositories, where builds for packages can depend on other packages in the personal repository.
Other, less significant but more achievable things I'd like to do:
- Formalise the process for submitting to official package repositories. In practice, this should be more about documentation and talking to repository maintainers than writing code.
- Custom MIME Type support (i.e. declaring a new made-up file suffix and its association with an application).
- See if I can get hardware related functionality (audio, USB) to work with Docker.