pyinfra-dev / pyinfra-dev/pyinfra
Decide & document what operations/facts should/should-not cover
@Fizzadar is already working on this.
Since Oct 29, 2022.
- Dominant language
- Python
- Stars
- 6k
- Forks
- 548
- Avg merge
- 7d 17h
- Merged PRs (30d)
- 13
Description
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.