Sparrow6 VS Inline-Perl5

Please pay attention if you want to dig really deep )) , then underlying SparrowCI itself is just a transpiler from YAML ( plus some more features ) into Sparrow DSL which is documented here - https://github.com/melezhik/sparrow6 but you probably don’t need that part if you are only interested in writing pipelines …

As an addition to what's been already said, you might distribute your personal libraries as Sparrow plugins and spin up a private Sparrow repo for that - https://github.com/melezhik/Sparrow6/blob/master/documentation/repository.md , it should not be very hard and by they way Sparrow is well integrated with zen by using Rakufile mechanism - https://github.com/melezhik/Sparrow6/blob/master/documentation/development.md#package-managers , so one can distribute any ref modules (including taken from git , not eco system ) by just including Rakufile into one's plugin ...

I think alternatives to Ansible such as Rex and Sparrow have "fake it and show me the commands" modes — but I'm not 100% sure.

I'm not sure if there is a full fledged web framework for Raku just yet, but one of its claims to fame is Sparrow. It's declarative configuration management akin to Puppet, Chef, or Ansible.

Sparrow an automation framework, and its modules

During this stage Bird will use prepared task checks rules (check file - /root/.bird/285892/state.check]) and run them against the output. Bird will use Sparrow task check DSL to do so.

1) Sparrow - https://github.com/melezhik/Sparrow6 Raku Automation Framework ( alternative to ansible )

Sparrow is a wonderful tool to automate @daily devops tasks. Recently I've dropped a new plugin called k8s-deployment-check to verify k8s deployments. It lets you with a little bit of Raku code effectively test entire k8s infrastructure, including k8s deployments.

Could be added pretty easily, Sparrow has cpan-package primitive for for that.

Verbatim from the documentation at https://github.com/niner/Inline-Perl5: use Inline::Perl5;

> Perl 6 was treated as the successor of Perl 5 -- and that was the mistake. It meant Perl 5 started dying,

Perl 6 took a long time to make, but how much did that matter? What was Perl going to do about Rails, Clojure, Go, Rust, JS/TS, and more? The world of programming languages used to be a lot smaller than it is today.

> Perl 6 had a new different syntax.

Inline::Perl5 [3] allows running legacy Perl 5 code in Perl 6 codebases.

[1]: https://docs.raku.org/language/5to6-nutshell#Regular_express...

[2]: https://github.com/atweiden/voidvault

[3]: https://github.com/niner/Inline-Perl5

Perl can be faster and defiantly nicer to work with than PHP but it's nowhere near as fast as some other options like Rust but that has the downside of being much harder to write and get working. Perl has the advantage of being prepackaged with the base system and on OpenBSD it's kept up fairly well with the system version currently being only one version behind the latest yearly Perl release. There are some patches added to the OpenBSD version so updating it each year takes time. The easiest way that I've found for running Perl websites is to leave the system modules as is and to install all of the modules that you need into a users home directory with local::lib and cpanm. That way the system install isn't contaminated with the extra modules and it makes deploying easy because it's all contained in one users home directory that can be rsync'd or tar'd. Another nice thing is you get access to pledge and unveil through Perl so you can lock down your website even further. I've recently been trying out doing things in Raku (Perl6 was renamed to Raku in 2019). It's slower than Perl most of the time but I find Raku to be so much more beautiful and expressive that it's a joy to code with. There aren't as many modules available right now for Raku but it gives you access to all of CPAN through the Inline::Perl5 module.

Interfacing with Perl 5 with Inline::Perl5:

I'll be happy to dialog about this compatibility, but the key thing is to start with an open mind; a recognition that the original vision predated Parrot; and a recognition that Rakoons have never relinquished that original vision even while many of us are delighted that Perl folk are keeping Perl healthy as a separate thing in its own right.

To be clear, the realization of Larry's original vision is not constrained to interop with Perl. Raku has extraordinary potential, some already realized, for pan-language compatibility via its [Inlines](https://modules.raku.org/search/?q=inline).

The steady improvement of [the exemplar Inline](https://github.com/niner/Inline-Perl5) for the last 6 years; its evident maturing; its suitability as a solid blueprint for upgrading all the others; all of this bodes well for being able to use a lot of the world's best existing code from within Raku this decade, with Inline::Python quite plausibly shining in this regard within the next 2-3 years.

[1] https://stackoverflow.com/a/45181464/1077672

The most polished of the Inlines, namely Inline::Perl5 (github repo) enables devs to instantiate Raku objects that are instances of Raku classes that are sub-classes of Perl classes. It does this even though Perl has pluggable OO, essentially arbitrary OO, with dozens of different OO systems available, all of which differ from Raku's, for example having a variety of MRO linearizations that aren't C3. So such things can be done.