Closed coke closed 2 months ago
(also: perl6 vs. raku executable choice)
What happens if you set both? 🤔
What happens if you set both? 🤔
You still get the warning:
➜ ~ RAKULIB=lib PERL6LIB=lib raku -e 'use a'
===SORRY!=== Error while compiling -e
Could not find a in:
/Users/coke/lib
/Users/coke/.raku
/Users/coke/.rakubrew/versions/moar-2024.08/install/share/perl6/site
/Users/coke/.rakubrew/versions/moar-2024.08/install/share/perl6/vendor
/Users/coke/.rakubrew/versions/moar-2024.08/install/share/perl6/core
CompUnit::Repository::AbsolutePath<6433437033688>
CompUnit::Repository::NQP<6433385012120>
CompUnit::Repository::Perl5<6433385012160>
at -e:1
Saw 1 occurrence of deprecated code.
================================================================================
The PERL6LIB environment variable being set, support will be removed with v6.e.
Please use RAKULIB instead.
--------------------------------------------------------------------------------
Please contact the author to have these occurrences of deprecated code
adapted, so that this message will disappear!
I think we can fix that :-)
https://github.com/rakudo/rakudo/commit/e335344c96 aka: ignore PERL6LIB
if RAKULIB
is also specified.
OK, but can't we just use RAKUDOLIB in Blin instead? I did not know it existed. Then maybe that commit is not needed.
RAKULIB is 2 characters shorter. That's the only difference, except now if you specify RAKUDOLIB and PERL6LIB, you will get the deprecation warning again.
What I meant is that we can specify just RAKUDOLIB. Then it's compatible with both old and new rakudo versions. Perfect for Blin.
Going forward, we want to use RAKULIB when invoking our tests, not PERL6LIB, to avoid getting deprecation warnings (And eventual failures when support is removed)
If we just change it, we'll have issues where we can't test older versions of raku because they don't yet support RAKULIB.
We should still make the switch now (main use of blin is testing for the latest release of the software), and consider if it's worth trying to avoid the error in the other case (maybe we offer a CLI flag that turns on both that folks can use if needed)