Skip to content

Convert Python packages/applications to native Linux distribution packages.

License

Notifications You must be signed in to change notification settings

bwoodsend/polycotylus

Repository files navigation

Welcome to polycotylus!

MIT license ∘ P̶y̶P̶I ∘ D̶o̶c̶u̶m̶e̶n̶t̶a̶t̶i̶o̶n ∘ Source codeBug reports

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 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. And you can 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. You can register your application so that launch menus (e.g. Gnome's App tiles) and file browsers know that your application exists, have icons and descriptions, and are aware of their supported file types.

Supported distributions

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 almost 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.20, edge
Arch rolling
Debian 13 (pre-release)
Fedora 37-40, 41 (pre-release), 42 (rawhide)
Manjaro rolling
O̶p̶e̶n̶S̶U̶S̶E Redacted due to too many upstream issues
Ubuntu 23.04-24.10
Void rolling

Development status

This project is not complete. It is not available on PyPI. To use this project as it is right now, 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 [email protected]:bwoodsend/polycotylus
cd polycotylus
pip install -e .
pip install -r docs/requirements.txt
cd docs
make html
xdg-open build/html/index.html

In 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.

That said, if you don't need any of the above then polycotylus should work for you.

About

Convert Python packages/applications to native Linux distribution packages.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published