Not compatible with Rakudo 2023.04 and older

[2colours]

With 466dad5, the code references Pod::Block::Input which is a type only introduced with rakudo/rakudo@6f482ca, hence the dist installation will fail with older versions of Rakudo.

Actually, there should be a strategy to prevent situations like this. I don't know whether Rakudo shouldn't create situations like this, the dist should be more conservative, or the dist should simply say the appropriate compatibility level.

[finanalyst]

@2colours Does Raku::Pod::Render actually fail on older versions of Rakudo? Liz told me that Roast contains tests of PBOutput and PBInput, but they were always mapped onto PBCode.

No one uses PBInput or Output, so I can disable them for Raku::Pod::Render.

[2colours]

@finanalyst yes, it does. Somebody reported this on IRC with 2023.04 and I can confirm. The type constraint used is invalid.

[finanalyst]

@2COLORS I've a lot of problems to work on at present and not much time. I'd be happy to revert the change. How is the error being seen? How can I test whether a workaround doesn't cause a similar problem? Richard

…

On Sun, 10 Dec 2023, 13:42 Márton Polgár, ***@***.***> wrote: @finanalyst <https://github.com/finanalyst> yes, it does. Somebody reported this on IRC with 2023.04 and I can confirm. The type constraint used is invalid. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACYZHB6LAKZLAAKBR6P52DYIW33PAVCNFSM6AAAAABALREOB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYHE3DSMRTGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[2colours]

The direct error is that the signature of handle candidates refer types that didn't really exist a couple of months ago. The size and complexity of the commit doesn't really help me estimate the actual influence.

As I said, the error is easy to reproduce with rakudo v2023.04. I just set it up with rakubrew and then tried to install the dist with zef.

[finanalyst]

@2colours That explanation really helps. I added two new handles to deal with the new types. I had not expected there to be an error.

I'll try to find a workaround.

[finanalyst]

@2colours I think the failure may be arising because the input/output is tested. I have made the tests compiler dependent, so compiler version 2023.04 or earlier does not render or test this POD.

I do not think =output or =input is used at all in the documentation suite, so an error should not arise.