link to third party extensions in docs

[adabru]

Related: https://github.com/Fizzadar/pyinfra/issues/12

Is your feature request related to a problem? Please describe

I'm a newbie to pyinfra and was looking for third party extensions as the core operations and facts are non-extensive. Specifically I couldn't find a ufw or hcloud (hetzner cloud) operation/fact in core (https://docs.pyinfra.com/en/1.x/operations.html). I skimmed through the doc, website and readme for the place where I could browse third party extensions but didn:'t find a clue there. I did a search on pypi for "pyinfra" and found some of them. https://github.com/Fizzadar/pyinfra/issues/12 lets me assume there isn't any guidance on distributing third party extensions yet. I'm coming straight from ansible by the way.

Describe the solution you'd like

Abstract: discoverability of extensions, encouragement and guidance to create them.

What comes to my mind is:

• a link to https://pypi.org/search/?q=pyinfra- in the docs and on the homepage
• a section https://docs.pyinfra.com/en/1.x/api/facts.html#distributing and https://docs.pyinfra.com/en/1.x/api/operations.html#distributing
• a github repository and a pypi package "pyinfra-extension-sample" or a link to a good working extension that can act as template
• a doc-section "USING PYINFRA -> Third-Party Extensions"

[benridley]

I think it'd also be useful to clarify the overall position of the project when it comes to expanding operations. Is it intended to be a 'batteries included' type project where community developed operations are encouraged to be merged into the main project, or do we want to encourage a more modular approach?

I think it'd be useful to have a dedicated registry of pyinfra modules for ease of search, but link to PyPi for actual distribution.

[Fizzadar]

Apologies for the big delay here - definitely want to implement the suggested ideas.

Regarding project - although the line is not exact, I'd like to keep pyinfra itself limited to "system level single state defintions" (if that makes sense), eg:

• install this apt package
• run this systemd service
• make sure this iptables rule exists

And avoid stuff like:

• deploy this nginx website (ie install package, write config file, start service)

Then there's things like docker/git operations, which kind of sit in the middle. I'm very wary of potential scope creep with this apporach, and will probably be something that we'll have to figure out as time goes on. Worst case scenario v3 could split out some of the builtin operations if needed, but I'd like to avoid that if possible :)

[adabru]

Keeping the project/core siim seems nice to me. Still there are usecases where e.g. "deploy this nginx website" is very desirable for users. I'd also take ufw and hcloud into the same bucket, though with a smaller userbase. As I wouldn't want the core people to bother with that stuff I guessed having separate extensions with separate maintainers is a nice scheme. That way, e.g. nginx operations/facts can be created as extension without affecting core and without need of core reviewers. Furthermore the extension can be abandoned without affecting core. Creating extensions is already possible just not very visible in my opinion.