Support installation using OS package managers (deb,rpm,...)

[ar406]

Official documentation explains how to install PyInfra using uv or pip.
This is great, but I feel like an alternative solution should be packages like deb for Debian derivatives or rpm for CentOS/Fedora derivatives.
This would help with deploying PyInfra in environments where packages are preferred due to cross-language consistency, as pip is Python only, whereas deb/rpm provide a consistent interface to install and list installed software regardless of the language.
There are a lot of sources on how to do this with Python code, including:

• FPM https://fpm.readthedocs.io/en/latest/packages/virtualenv.html (both deb and rpm)
• dh_virtualenv https://dh-virtualenv.readthedocs.io/en/1.2.1/ (deb specific)

[wowi42]

IMHO: Why OS Package Manager Support is Not a Good Idea

1. Maintenance burden with minimal benefit

Creating and maintaining deb/rpm packages requires significant ongoing work: CI/CD pipelines, testing across distros, package signing, hosting repositories, handling security updates. For a small project, this diverts resources from actual development.

2. pyinfra runs on the operator's machine, not managed hosts

pyinfra is a CLI tool you run locally to manage remote systems. It's not a daemon or system service that needs to be installed via apt/yum. The operator can use pip/uv/pipx regardless of what package managers exist on the target hosts.

3. uv/pipx already solves this cleanly

pipx install pyinfra
# or
uv tool install pyinfra

One command, isolated environment, no conflicts with system Python, works on any OS.

4. System Python packages cause more problems than they solve

deb/rpm Python packages are notorious for dependency conflicts with system libraries, version pinning issues, and breaking on OS upgrades. A virtualenv-based install is actually more reliable.

5. Version lag

OS packages typically lag weeks or months behind PyPI. Users filing bugs would often be told "upgrade to the latest version" which defeats the purpose.

6. "Enterprise compatibility" is a weak argument

Enterprises that mandate deb/rpm packages have their own packaging teams. They don't expect every upstream Python tool to ship native packages — they build them internally with their own policies.

Conclusion: The existing pip/uv installation is simpler, more portable, and more maintainable than distro packages would be.

[wowi42]

@ar406 if you are at FOSDEM, we can discuss it face to face

[zilti]

Usually, OS packaging systems nowadays have a functionality to generate packages from language-specific package managers. This project has a pyproject.toml, so it's trivial to do; I just did that for Guix. So if someone using a distribution wants packages for it, it is easy enough for them to maintain themselves.