"Can't locate App/cpanminus/script.pm in @INC" error on perls < 5.8.0 about cpanminus HOT 20 CLOSED

What about, "Sorry, we're not supporting 5.6"?

I'm serious.

from cpanminus.

Yeah, that's an option :-)

But a) it wouldn't be hard for someone who isn't afraid of App::FatPacker's code (i.e. someone who isn't me) to splice in IO::String; b) cpanminus doesn't specify a minimum version anywhere, so I assumed it was aiming for portability; c) I fired up 5.6.2 to test some fixes I made to a module (not mine) whose minimum version is 5.6.1. There are plenty of pure Perl modules that don't require modern Perl (and plenty of shared hosting plans stuck on 5.6.1 or even 5.005.003). I was hoping cpanminus could sprinkle its usual fairy dust and make that journey into the past pleasant.

It's not just a "dinosaur shop stuck in 2000" thing; it's also a "make sure you haven't broken anything" testing thing.

from cpanminus.

Also: barring more runtime surprises, everything cpanminus depends on (and cpanminus itself) works (and installs) fine in 5.6.2. It's only one line in App::FatPacker that's backwards-incompatible.

from cpanminus.

Well, the document says it requires 5.8 - although it's suggesting that it might work on 5.6. At some point it was true, but at the Vienna hackathon i decided not to care too much about < 5.8.

Well if it's really easy to patch App::FatPacker and mst accepts it, i can make it compatible to 5.6, but at this point i'd just say we need 5.8.

Since cpanm feature development is almost frozen, someone could actually fork the code and make it not rely on FatPacker, and release it as cpanm56 or something like that..

from cpanminus.

i can make it compatible to 5.6

You don't have to. Unless there are more runtime surprises, it's not a direct cpanminus issue (it's just a meta (i.e. metadata) issue).

Since cpanm feature development is almost frozen,
someone could actually fork the code and make
it not rely on FatPacker, and release it as cpanm56
or something like that..

1/5835 of cpanminus is not compatible with older perls. Seems like an unwise fork to me, to say the least.

And this isn't a feature. It's a bug.

from cpanminus.

By "make it compatible to 5.6" i mean to "support" 5.6.

At this point I don't have an intention to do it, so I'll remove that confusing document saying "it may work with 5.6".

from cpanminus.

• The commit message is wrong - this has nothing to do with coderefs in @inc.
• Changing the documentation doesn't change the fact that it installs on 5.6.2, but doesn't run on it.
• You don't need to "support" 5.6.2 to fix this. It's a bug in App::FatPacker that breaks cpanminus. Reporting it here was just a courtesy.

from cpanminus.

RIght, I could add "use 5.008000" in Makefile.PL to stop it being installed on < 5.8 so i can be more explicit about that. Do you want me to do it?

from cpanminus.

I don't think it's a bug in FatPacker. I'm sure mst won't accept it and he'll add use 5.008000 on it.

Actually local::lib, also included in cpanminus, requires 5.8. I wonder how it doesn't blow up in runtime.

from cpanminus.

I wonder how it doesn't blow up in runtime.

It doesn't get that far.

I don't think it's a bug in FatPacker.

It's a bug in cpanminus (caused by a bug in App::FatPacker) that it installs on a version of perl it doesn't work on.

from cpanminus.

It's a bug in both modules that that they install on a version of perl they don't work on.

Right, so you're suggesting me to put require 5.008000, right?

from cpanminus.

Done in 11a8904.

It's just in Makefile.PL so it may still work if you install from curl/wget, but that's something "you want to shoot your own feet" thing so I'll leave it as it is.

from cpanminus.

Right, so you're suggesting me to put require 5.008000, right?

If local::lib can't be made to work on 5.6.x, then yes, of course. If local::lib only "requires" 5.8.1 because it hasn't been tested on a lower version, then no, of course not.

from cpanminus.

Done in 11a8904.

I guess it was a rhetorical question.

from cpanminus.

There's no reason you should NOT do "require 5.8" even if the code itself actually runs fine on < 5.8: that is to reduce the cost of "supporting" modules on CPAN. You're a prolific CPAN author so you should understand how that goes when you have 180 modules on CPAN.

On the other hand, the other radical approach to this problem is "I don't care", like what I've been doing with cpanminus. Because it has zero tests in t/ (other than just ok 1 to make testers happy) and the code itself mostly runs fine on < 5.8, putting the code to CPAN with the doc "it may work with 5.6 but we don't support it" is clearly one way to do this.

And now you're saying a) if a module that doesn't have 'require 5.8' installs fine and fails at runtime < 5.8 is a bug and b) if it's "easy" to make it run on 5.6 it's a "bug" and should be fixed.

I think a) is more right in the long term, so i fixed it.

It's really unfortunate that we came up with this solution. If you didn't call it a bug, I would keep it as it is with a big warning in the doc "it may install on 5.6 but probably doesn't work".

from cpanminus.

I reverted 11a8904 - maybe I will put more text in the documentation.

from cpanminus.

There's no reason you should NOT do "require 5.8" even
if the code itself actually runs fine on < 5.8

I agree. (I had to parse that a few times due to lack of coffee :-)

It's really unfortunate that we came up with this solution.

It's not my solution. I was trying to use cpanminus to help me run some tests on 5.6.2. "Sorry, we're not supporting 5.6" minimizes surprise, sure, but certainly isn't ideal. If someone knows why local::lib doesn't work on perls < 5.8.1, then please let me know. I've already done as much as I can (to start with; I'm happy to investigate further if needed) to address the compatibility issue with App::FatPacker.

from cpanminus.

Right, we agree that this is not an ideal solution - reverted the commit.

I don't know what was the reason for local::lib not supporting 5.6 but I guess it was exactly as you guessed: nobody has bothered testing it and supporting it.

Well actually, the functionality cpanm uses out of local::lib is basically now (almost) in lib::core::only (just pushing core only paths into @inc and removing everything else, including vendors), so it'd be possible and easy to remove the dep on local::lib here.

I still don't know about FatPacker - if I were mst i wouldn't bother spending time supporting 5.6, but if you could provide a patch you can drop in, he may accept it, but who knows.

Thanks for bringing up the issue and discussion. I hope my view on this is clear: I'm happy to make it run on 5.6 but won't spend any further time than 5 minutes to make it do so, and have no intention to actually state that it "supports" 5.6.

from cpanminus.

if I were mst i wouldn't bother spending time supporting 5.6,
but if you could provide a patch you can drop in, he may accept it, but who knows.

If he asks for one, I'm happy to have a go. I suspect it would take me hours and mst a few minutes, though.

I'm happy to make it run on 5.6 but won't spend any further time than 5
minutes to make it do so, and have no intention to actually state that it
"supports" 5.6.

That's fair enough, and I totally understand/agree.

from cpanminus.

I was trying to get a cpanm bootstrap on 5.6.2 because I had a test for one of my modules failing and It was somewhat pesky. There is a reasonably obvious hack that works, its somewhat dangerous because it makes assumptions about temporary directories and file permissions somewhat, so its not a "ready for primetime" hack, but its a hack people can themselves add to downloaded cpanm instances to get it working. ( For Now )

my $i = 0;
unshift @INC, sub {
  if (my $fat = $fatpacked{$_[1]}) {
    my $fatfile = "/tmp/fat_pack_" . $i; 
    $i++;
    open my $wfh, '>', $fatfile or die "Error opening file";
    print { $wfh } $fat;
    close $wfh;
    open my $fh, '<', $fatfile;
    unlink $fatfile;
    return $fh;
  }
  return
};

from cpanminus.