pypyr is open source. Your contributions are most welcome.
Feel free to join the pypyr discussion on the pypyr community discussion forum.
Well, you know. No one’s perfect. Feel free to create an issue.
The usual jazz - create an issue, fork, code, test, PR. It might be an idea to discuss your idea on the discussion forum or via the Issues list first before you go off and write a huge amount of code - you never know, something might already be in the works, or maybe it’s not quite right for the core-cli (you’re still welcome to fork and go wild regardless, of course, it just mightn’t get merged back in here).
You’ve probably noticed by now that pypyr is built to be pretty extensible. You’ve probably also noticed that the core pypyr cli is deliberately kept light. The core cli is philosophically only a way of running a sequence of steps. Dependencies to external libraries should generally get their own package, so end-users can selectively install what they need rather than have a monolithic batteries-included application.
If you’ve got some custom context_parser or steps code that are useful, create a repo and bask in the glow of sharing with the open source community. Honor the pypyr Apache license please.
I generally name plug-ins
is likely some sort of dependency that you don’t want in the pypyr core
cli. For example, pypyr-aws contains pypyr steps for the
boto3 library. This is kept separate so that you don’t have to deal
with yet another dependency you don’t need if your current project
isn’t using AWS.
If you want, for cred on the official plug-in list, please feel free to get in touch via the Feedback link on this page. Get in touch on twitter anyway, would love to hear from you!