Closed atcroft closed 1 year ago
Realized there was a newer version. Installed berrybrew v.1.36, and see the same behavior as listed above when run with v.1.34.
On the roadmap. Thank you for such detailed feedback. Actually, it's remarkable feedback.
I have figured out why this is happening. Essentially, when temporarily use
ing a perl, berrybrew
doesn't know that it's the perl in use. It recognizes the previously switch
ed version as the one to use for exporting modules. The check happens in PerlInUse()
, so I will look at whether this can be sanely changed, or whether it'll be best to throw a warning that export can't happen in a temporary perl.
Another issue related though, is that the module export routine can't be run on 5.10.1
. I can't remember why right now, but it's clear that it was an explicit decision because something wasn't working:
StrawberryPerl perl = PerlInUse();
if (string.IsNullOrEmpty(perl.Name)) {
Console.Error.WriteLine("\nno Perl is in use. Run 'berrybrew switch' to enable one before exporting a module list\n");
Exit((int)ErrorCodes.PERL_NONE_IN_USE);
}
if (perl.Name == "5.10.1_32") {
Console.Error.WriteLine("\nmodules command requires a Perl version greater than 5.10\n");
Exit((int)ErrorCodes.PERL_MIN_VER_GREATER_510);
}
Fixed in 1.38.
We no longer allow using berrybrew modules export
in a temporary, use
ed instance.
Commands:
berrybrew use --win 5.10.1_32
perl -v
perl -le "foreach (@INC) { print; }"
berrybrew list
berrybrew available
berrybrew modules export
berrybrew version
Actual behavior:
<berrybrew use perl-5.10.1_32>
<berrybrew use perl-5.10.1_32>
<berrybrew use perl-5.10.1_32>
<berrybrew use perl-5.10.1_32>
<berrybrew use perl-5.10.1_32>
<berrybrew use perl-5.10.1_32>
<berrybrew use perl-5.10.1_32>
Expected behavior:
Expect 'use $version' to result in modules list for $version. (In the example above, the expected module list to be output would be for 5.10.1_32 instead of 5.32.1_64 listed.)