How will we differentiate version specific modules?

[drmuey]

Thanks for setting this FAQ up ;)

This question is similar to the binary name FAQ (perl, perl7, perl8, …): How will we differentiate version specific modules?

One approach could be extension:

• Foo.pm ➜ 5
• Foo.p7m ➜ 7
• Foo.p8m ➜ 8

Could be other pragma type stuff but that seems a little like what 7 is wanting to avoid.

maybe simply a module that barfs if its too low?

use Perl::MajorVersion 7;

but then thats more boilerplate which we’re trying to get away from.

🤔

[briandfoy]

I see this question, and I don't have an answer.

I think the most likely case is the same thing we do know. Perl modules go into version specific directories. I personally wouldn't want new file extensions. Perl 7 is going to act very much the same as v5.32. Here's the default @INC for the v5.32 I just installed:

  @INC:
    /usr/local/perls/perl-5.32.0/lib/site_perl/5.32.0/darwin-2level
    /usr/local/perls/perl-5.32.0/lib/site_perl/5.32.0
    /usr/local/perls/perl-5.32.0/lib/5.32.0/darwin-2level
    /usr/local/perls/perl-5.32.0/lib/5.32.0

Notice the 5.32.0 after the lib. Now imagine that as 7.0.0 instead. Perl 7 loads from it's directories and Perl 5 from its directories. Consider the situation where a module needs v5.20 but you try to install with an earlier Perl. If the module author has but a minimum version in the Makefile.PL, it won't run (so won't install).

I think the idea is that in Perl 7, we'll assume that use v7 is already there, but there's not a ruling on that yet. That's fine if you are on Perl 7, but Perl 5 knows nothing about later decisions.

There will also be some sort of module compatibility mode.