Not sure about Raku, as I'm not using it. As a Perl user I would like the grants to be focused mostly on Perl core (C code and the shipped modules), at least primarily and for few years (esp. during the new "class" era). Perl comes with almost every Unix-like distribution, and improving it could significantly contribute to reviving and expanding its use in production where those systems are used extensively.
The work in this proposal would be extremely beneficial to the Raku ecosystem – it would provide the final missing piece for Raku to have a genuinely modern and ergonomic library story, without relying on external services like CPAN or GitHub.
I won't go into the technical details here – the proposal itself does a good job of laying those out, and other Rakoons are far more versed in the details than I am. But I'm slightly concerned that the proposal doesn't fully explain the big picture, especially to those who haven't been following the behind-the-scenes details of how Raku software is delivered.
So here's the big picture:
• Raku software is typically installed using the Raku package manager, Zef (https://github.com/ugexe/zef). For example, `zef install JSON::Fast`.
• Zef can install Raku software that has been uploaded to a variety of different "ecosystems" – originally, for public modules, mostly CPAN; later, also a (GitHub-backed) p6c ecosystem. This functionality also supports private/custom ecosystems.
• For a variety of reasons, neither CPAN nor p6c/git are a great fit for Raku – they (understandably!) don't support the features that Raku needs for proper versioning/authentication. (And, of course, using them ties Raku to platforms it doesn't control). See https://deathbyperl6.com/faq-zef-ecosystem for details.
• To solve ^^^^, Raku is transitioning to the Fez ecosystem, which is built to provide what Raku needs.
• Fez has two parts: First, a front-end CLI client that lets programmers register themselves and upload authenticated code, e.g., with `fez upload`. This front-end is written in Raku; its code is at https://github.com/tony-o/raku-fez
• Fez also needs a back-end to handle the authentication, store the code, and make it searchable by Zef. Right now, this back-end is (despite running wonderfully in production) basically a proof-of-concept version – it's written in Go, isn't public, and doesn't provide many of the advanced features that are possible when the front-end and back-end can work together (better group management, more efficient downloads, etc.).
With that context, you can probably see where this grant proposal fits in: the work covered by this grant would rebuild the back end in Raku and would add many of those advanced features. It would effectively complete Raku's transition to Fez as its primary public ecosystem; it would improve the Fez ecosystem in the short term; and, by opening up the back-end code, it would set Fez up for continued improvement. I really hope it gets funded!
I am in support of this grant. Having the ecosystem code open sourced and ported from Go to Raku would itself be a huge boon. It would allow the community to have more insight into policy (such as namespace ownership, meta data validation). People interested in contributing to improving the Raku ecosystem are likely to be more interested in contributing Raku code they can run locally rather than a cloud lamda written in an unrelated language, and so I think this proposal would continue to pay dividends as time goes on.
A robust, ecosystem-wide, and well-documented user management system is the thing we're missing. It's literally the key to any long-running distributed software project.
Projects like ours face a paradox:
We want to let a thousand flowers bloom. It's the spirit of Perl and Raku. We don't want to force everyone to use a single platform. For instance, Andinus was motivated to stand up OpenBSD servers for hosting various Raku websites this year. I didn't know anything about it, but his intrinsic motivation and skills proved it out, and I have benefitted from learning from him. This sharing can never happen if we behave like a corporate enterprise with a narrowly-proscribed list of "approved software".
But people come, do good work, and go away for a while. How do we harness this energy while they're here? How do we save their spot, for when they're ready to come back? The answer is documented, secure user management that lives outside the database of corporate SaaS platforms. Users and groups are quite literally the software representation of the community, and it benefits from a little bit of centralization. Kudos to Tony for the proposal.