Fizzadar
commented
2 years ago 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 https://github.com/Fizzadar/pyinfra/issues/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
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.
Extended System
Manage what are considered system components but that require installing ontop of a base system (ie brew on MacOS).
User Software
Manage specific softwares that get installed in a system.
Other
Just the
python.*operations which provide Python callback support.