[bug#57491] [PATCH] patch series: Update Raku ecosystem

[Maxime Devos]

On 08-09-2022 04:18, Daniel Sockwell wrote:
> (If this was already the case in the previous version, that's still bad,
> > but then it can be left for later, being independent of this patch.)
> Understood.  I'll put that on the to-do list for future patches (though
> pinning specific versions of MoarVM/Rakudo to specific versions of the UCD
> is important, so unbundling might mean including more up-to-date versions
> of the UCD, unless Guix already stays very current there).
If having a specific version (and not just a sufficiently recent version)
is important, you can look at the 'ucd-next' package and make a similar
package variant, except for whatever version MoarVM and Rakudo need
> > I noticed you removed the mention of the garbage collector, is this
> > intentional?
> I cut the GC from the list of features in an effort to stay within Guix's
> length guidelines for descriptions (and because having a GC doesn't do much
> to distinguish Raku from Perl/Python/nearly all Lisps/JS, etc.)  But the GC
> is very much still present :)
OK.
> > On nqp-configure: Are you sure that 'bin' should be installed in '.../bin'?
> > Looking at the Git repository, make.nqp does not have a shebang and can hence
> > not be directly run, maybe you should add a shebang?
> >
> > Also, is there appear to be some tests in 't', why aren't they run? There is a
> > 'rakudo-build-system', maybe this rakudo-build-system can properly build this
> > package
> I'll double check the above.
>
> > On nqp: why the switch from downloading the source code from the apparent 
> > official site
> > "rakudo.perl6.org" to GitHub?
> The Rakudo site no longer hosts NQP, just Rakudo.  See 
> https://rakudo.perl6.org/downloads
OK.
> > > + (substitute* "t/09-moar/01-profilers.t"
> > > + (("ok.*\\$htmlpath" html-test-text)
> > > + (string-append "todo \"harness5 fails to write html profile\";"
> > > + html-test-text)))))
> > What's the issue here? Is it a limitation of the Guix packaging, or could it 
> > perhaps
> > be an upstream bug? If the latter, upstream needs to be informed such that they 
> > can
> > fix the bug.
> I'm honestly unsure.  I can't understand why it would be a Guix-specific issue, 
> but I've
> also never had that test fail when building from source on other distros.  More 
> investigation
> is called for.
OK, I suppose it isn't a blocker.
> > On the new package description: ... It's getting close to marketing phrases
> Thanks.  I could tell I was getting a bit close to that line and guess I let my 
> enthusiasm
> carry me away a bit; I'll rein it in.
>
> > Can you verify that our various perl6-... libraries still build, and that when 
> > doing, say,
> > "guix shell rakudo perl6-json-name -- whatever-rakudos-binary-name-is", you can 
> > still use
> > perl6-json-name in whatever is rakudo's name for a REPL?
> Will do.  (Everything *should* be backwards compatible, but it's 100% worth 
> checking)
I meant, the rakudo-build-system expects PERL6LIB, but the package now has a
RAKULIB search path instead.
> > You add some patches, but they need to be registered in gnu/local.mk as well, 
> > please do so.
> Will do.
>
> > On the patch file name: it looks a little suspect, perhaps if you run the 
> > linter on the
> > packages it will have a comment about the file names.
> I ran the linter and its only comment was that patches need to start with the 
> package name.
Possibly it expects the package name to be followed by a - instead of a .
> Is there another rule?
Patches should have a comment at the top explaining what they are for, 
but you already did that.

Greetings,
Maxime

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature