Raku exists in portage but its module installer zef does not. The following Raku language related packages are present: dev-lang/rakudo dev-lang/nqp dev-lang/moarvm Those packages are the bare minimum required to build and run the language. But without zef, it's not possible to plug into the Raku ecosystem and install modules. This is every bit like having a Python package and no pip or a Perl package and no cpan client, etc. Reproducible: Always Steps to Reproduce: emerge --ask dev-lang/zef Actual Results: emerge: there are no ebuilds to satisfy "dev-lang/zef". Expected Results: The ebuild dev-lang/zef should exist. The zef module installer source code is available on GitHub at https://github.com/ugexe/zef and releases are tagged.
dev-lang/rakudo should install tools/install-dist.raku. install-dist.raku should be used to install every raku module including zef. install-dist.raku should be used in rakudo.eclass.
zef cannot cleanly handle installing raku modules as gentoo packages, but install-dist.raku can.
zef is great if you want to install raku modules as a non-root user into ${HOME}/.raku
To dev-lang/rakudo-xxx.ebuild, I needed to add the following lines to src_install so that installing and removing zef doesn't remove directories created by rakudo. newbin tools/install-dist.p6 raku-install-dist raku="$D/usr/bin/raku" func="CompUnit::RepositoryRegistry.repository-for-name" site=$($raku -e "say $func('site')") site=${site#inst#} keepdir "$site/bin" keepdir "$site/dist" keepdir "$site/precomp" keepdir "$site/resources" keepdir "$site/short" keepdir "$site/sources" vendor=$($raku -e "say $func('vendor')") vendor=${vendor#inst#} keepdir "$vendor/bin" keepdir "$vendor/dist" keepdir "$vendor/precomp" keepdir "$vendor/resources" keepdir "$vendor/short" keepdir "$vendor/sources"
Created attachment 766797 [details] rakudo.eclass This is the secret sauce.
Created attachment 766798 [details] dev-raku/zef-0.13.7.ebuild Behold.
Created attachment 766799 [details] dev-raku/Digest-MD5-0.05_p20170425.ebuild This is a minimal example of a raku module.
Created attachment 766800 [details] rakudo.eclass My secret sauce.
Created attachment 766801 [details] rakudo.eclass
Created attachment 766804 [details] rakudo.eclass
Created attachment 766805 [details] dev-raku/zef-0.13.7.ebuild
Perhaps, I should install raku-install-dist as /usr/share/perl6/core/tools/install-dist.p6
I added rakudo.eclass, my own version of dev-lang/rakudo, dev-raku/zef, and dev-raku/Digest-MD5 to my overlay. Check them out, and add them to gentoo overlay.
rakudo.eclass requires my version of dev-lang/rakudo. Be careful.
My crocket-overlay now contains dev-raku/zef for development, dev-raku/App-Prove6 for tests, and dev-raku/Inline-Perl5 for interoperation with perl 5. rakudo.eclass has been nearly perfected. Gentoo linux should just take rakudo.eclass, dev-lang/rakudo, and dev-raku/* from my overlay.
(In reply to crocket from comment #15) > My crocket-overlay now contains dev-raku/zef for development, > dev-raku/App-Prove6 for tests, and dev-raku/Inline-Perl5 for interoperation > with perl 5. > > rakudo.eclass has been nearly perfected. > > Gentoo linux should just take rakudo.eclass, dev-lang/rakudo, and dev-raku/* > from my overlay. To submit them, attach a git am-able patch (from git format-patch) and also submit the eclass to the gentoo-dev ML via git send-email.
(In reply to Sam James from comment #16) > To submit them, attach a git am-able patch (from git format-patch) and also > submit the eclass to the gentoo-dev ML via git send-email. Is this the only way to submit a patch? Is there any documentation on submitting changes to gentoo ebuilds?
(In reply to crocket from comment #17) > (In reply to Sam James from comment #16) > > To submit them, attach a git am-able patch (from git format-patch) and also > > submit the eclass to the gentoo-dev ML via git send-email. > > Is this the only way to submit a patch? Is there any documentation on > submitting changes to gentoo ebuilds? In general: - make a change locally - git commit it (ideally use 'pkgdev commit') - when you're done, either push it to a branch somewhere, and open a pull request, OR run 'git format-patch' and attach the patches which it makes in your directory to a bug. So, for eclasses, we have to send new eclasses to the gentoo-dev mailing list. You can do this by using the 'git send-email' command. For general contributions, you can attach those git format-patch patches to bugs, but sometimes it works better to make a PR on github, it depends on the maintainer. https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide#How_to_submit_package_updates tries to explain it but I can give more info
If there are no consumers in ::gentoo, consider contributing to GURU: https://wiki.gentoo.org/wiki/Project:GURU
(In reply to Anna Vyalkova from comment #19) > If there are no consumers in ::gentoo, consider contributing to GURU: > https://wiki.gentoo.org/wiki/Project:GURU What do you mean, "if there are no consumers?"
I don't like mailing lists. I also don't feel comfortable about depending on microsoft infrastructure. I think gentoo project should create its own self-hosted gitea/gitlab instance.
(In reply to crocket from comment #21) > I don't like mailing lists. I also don't feel comfortable about depending on > microsoft infrastructure. > > I think gentoo project should create its own self-hosted gitea/gitlab > instance. You don't have to use microsoft infrastructure. I was just giving github PRs as an option. As for self-hosted gitlab, it's being worked on. But we do eclass review via mailing list. You can do the rest via Bugzilla if you wish.
(In reply to Jeff Gazso from comment #20) > (In reply to Anna Vyalkova from comment #19) > > If there are no consumers in ::gentoo, consider contributing to GURU: > > https://wiki.gentoo.org/wiki/Project:GURU > > What do you mean, "if there are no consumers?" If no packages in gentoo.git need it, you can do it in guru.
I wish mailing list was replaced with gitlab discussion or gentoo forum. At least, the forum interface is easier to use. I can't configure my webmail client properly.
