Decide & document what operations/facts should/should-not cover

[Fizzadar]

An always expanding builtin set of operations/facts is unmaintainable, it makes sense to decide where this should end and where operations as external packages should begin. Looking at the current set of operations I've roughly divided them as below, will discuss in separate comment:

Base System

Manage builtin system components ie file management, system package managers, system service managers, selnux. Anything considered the "core" of a target system/OS.

• apk
• apt
• bsdinit
• dnf
• files
• launchd
• pacman
• pkg
• pkgin
• selinux ? - is this right? is part of the Linux kernel but requires userspace component
• server
• systemd
• sysvinit
• upstart
• windows
• windows_files
• xbps
• yum
• zypper

Extended System

Manage what are considered system components but that require installing ontop of a base system (ie brew on MacOS).

• brew
• choco
• iptables ? - if selinux is above, so should this be?
• lxd
• openrc
• snap
• vzctl

Both of the above could be grouped as "system" for simplicity.

User Software

Manage specific softwares that get installed in a system.

• gem
• git
• mysql
• npm
• pip
• postgresql
• puppet
• ssh

Other

Just the python.* operations which provide Python callback support.

• python

[Fizzadar]

Looking at the list, one option would just be to say "system operations in, everything else out". But having things like postgresql builtin to pyinfra do seem very handy to have, if these were part of a pyinfra-database-operations package suddenly the barrier to entry is much greater. Likewise the git.* operations are such a common use-case it seems foolish to remove them from the "pyinfra stdlib".

The reason I bring this issue is because of #904 which feels like it should not be part of the core, but then were do we draw the line? I have no answers :)

[fliepeltje]

I think with good documentation and a sane API for writing operations and fact definitions, you could experiment with community driven addons, a bit inspired by something like faker: https://faker.readthedocs.io/en/master/communityproviders.html

You could also consider subdividing feature sets into extras: https://peps.python.org/pep-0508/#extras

so it would be more like pip install pyinfra[postgres, nginx]